I have multiple projects on Git that I eventually want to bring others into. However, right now it's just me and I use Git and GitHub very simplistically: no branches and basically just using the commits as a backup to my local files. Sometimes I'll go back and look at previous versions of my files for reference, but I haven't needed to do any rollbacks to this point, though I appreciate the option should I need it in the future.

As a sole developer, what Git or GitHub features could I take advantage of that would benefit me right now? What should my workflow be like?

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

  • 3
    As others have explained, Git gives you a lot of power. As a sole developer though, the big thing you will appreciate later is that if gives you a records of what changes you made (grouping changes in several files into one set), when you made them and why! It's also great practice for when you become part of a team. Commented Aug 7, 2014 at 13:59
  • 5
    Closed because interesting. :)
    – user93458
    Commented Apr 1, 2018 at 14:29
  • 3
    @user93458 as always! Closed topics are usually exactly what I'm searching for. Commented Jul 31, 2019 at 20:21
  • 2
    excellent question that should never have been closed.
    – volume one
    Commented Oct 22, 2019 at 14:55

5 Answers 5


Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

Of course. There is a simple good practice that you can use even if you don't have a team right now: create a separated branch for development. The idea is that master branch will contain only released code versions or major changes. This can be adopted easily by new developers that join your project.

Besides, branching is useful even if you are working solo. For instance, you find a bug while in the process of coding a new feature. If you don't use branches, you will have to do both: add new features and fix the bug in the same branch. This is not good :P On the other hand, if you had created a new branch for creating your new feature, you can just checkout the development branch, fix the bug, and checkout back the new feature branch.

This is just a brief example of what you can do being a sole programmer. I am sure there must be more good practices.

I highly recommend you this article: A successful Git branching model

  • 1
    I'm not a git specialist, mostly a Mercurial user. Does this dev branch advice still hold in the case of Mercurial? It looks like it does but maybe some differences makes it not a good idea in this case?
    – Klaim
    Commented Oct 13, 2011 at 21:54
  • 3
    Yes, it pretty much holds for all source control. I actually do it backwards with SVN; the "main" trunk is for the latest development, which goes in daily or even more often. When a release is called for, the code is frozen and a branch cut. That branch only gets minor updates to fix major release issues, and then the distributable is created from that. That way, I have a branch of the source code behind each released version. This is better than simply tagging or labeling b/c if commits come in after the label but before the release, you don't know if they were actually excluded.
    – KeithS
    Commented Oct 13, 2011 at 22:19
  • 1
    +1 for the article; @Klaim -- yup, works great for hg too. really should be called "successful DCVS branching model" Commented Oct 13, 2011 at 22:46
  • +1 thanks for the link, it changed the way I will work with git, not by much mind you but as they say, every little bit helps !
    – Newtopian
    Commented Oct 14, 2011 at 2:06
  • @KeithS: Yes, in Subversion you mostly have to do it in reverse, because it's merging support is somewhat lacking. In distributed systems the way described in the article is better. Since merging is symmetrical operation, it's mostly equivalent either way.
    – Jan Hudec
    Commented Oct 14, 2011 at 14:01

I'm exactly in this situation but I did opt for a slightly more complex though not necessarily more complicated workflow with Git.

The objective at first was learn the git way so I did some amount of exploring. then reverted to pretty much the workflow you described.

After a while this became difficult to work with as some situations arose also it gave me bad habits that would be hard to break once I join a team.

so I settled for the following :

  • Local repository for working.
  • Master branch as a stable trunk for the application
  • One branch for each feature / refactor, basically one branch for each sizable changes that will be done.
  • Merge back to trunk when the branch is stable and all tests pass.

I also setup a git hub account where I synchronize the trunk. This allowed me to easily start working on different computers. It was by necessity but allowed me to find bugs that were tied to the environment I was in which was not available on the other computers. So now I make it a habit to try a project on a different "virgin" system at least once. Saves me a lot of headaches when comes time to deploy to the customer.

  • I tag every versions that makes it into github as a releasable version.
  • If released to the customer I will branch from this version to create a second stable trunk for bug fixes declared by the customer.

The multiple branches at first seemed like overkill but it REALLY helped a lot. I could start an idea in a branch, work on it for a while and when I start running circles I gave up and started another branch to work on something else. Later an idea came where I would come back to the half baked branch and explore this idea. this overall made me MUCH more productive as I could act of flashes and ideas very quickly and see if it worked. The cost of switching branches with GIT is extremely low making me very nimble with my code base. That said I still have to master the rebase concept to clean up my history but since i'm all alone I doubt I really need to. Pushed it as "nice to learn".

When all the branching became complicated then I explored the log option to draw a tree of changes and see which branch are where.

Long story short, git is not like SVN, CVS or (brrr) TFS. Branching is very cheap and making mistakes that will wipe out work is actually pretty difficult. Only once did I lose some work and it was because I made my commits too big (see bad habits above). If you commit often, by small chunks git will definitively be your best ally.

To me git opened my mind to what source control really is all about. Anything else before was just attempts to get it, git is the first, that in my mind, got it. That said, I did not try other DVCS, quite possibly this statement could be widened to the whole family.

One last advice, the command line is your friend. Not to say that graphical tools are not good, quite the contrary but I really groked git when I dropped down to command line and tried it out myself. It is actually very well made, easy to follow with a very comprehensive help system. My biggest problem was being tied to the but ugly console in windows until I found alternatives.

Now I use both, Eclipse integration with Git to see what is going on in real time and do some operations like diffs, explore history for a file, etc. And command line for branching, merging, pushing, getting and the more complex log trees. some basic scripting and I've never been so productive with regards to source control and I never had so much control over my source.

Good luck, hoped this helped.


I'm well-versed in several sophisticated branching models, and use some at work. However, when I work alone on projects, I do pretty much exactly what you're doing now. I can always create a branch after the fact if I need one, but I almost never do. Working alone, I rarely have bug fixes that can't wait until my current task is finished. My advice is to be familiar with some branching models, but there's no sense complicating things until you need to.


For a simpler model, you can look at what GitHub does. "GitHub flow" is very simple, and there's an excellent guide here: https://guides.github.com/introduction/flow/index.html

Summary (from Scott Chacon's blog):

So, what is GitHub Flow?

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
  • Commit to that branch locally and regularly push your work to the same named branch on the server
  • When you need feedback or help, or you think the branch is ready for merging, open a pull request
  • After someone else has reviewed and signed off on the feature, you can merge it into master
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately

Sometimes I'll go back and look at previous versions of my files for reference....

For that TortoiseGit is helpful and it's free. It's great for identifying check-ins and comparing files across releases.

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?


Regarding workflows... there are plugins that hook into Jira. And you can make it so that upon checking in code it is compile-validated in a dedicated test environment. But going down that path takes you down the path of being a Git administrator, not a developer.

Not the answer you're looking for? Browse other questions tagged or ask your own question.