I'm starting to work with git for the first time, and I'm trying to come up with a workflow that works for me, so I thought of coming and asking around.

Right now, I'm in a couple of projects where I'm the only programmer and, in fact, the only pusher to origin.

I'm working like this, where c is a commit, p is a push and m is a merge:

             /                 /     \
        \                  /           \  

Now I've gathered that rebasing would be more "correct" than those merge master I do in the feature branches, or at least that's how it'd seem.. but I'm not sure I'm doing it right. What I've realized now is that by merging master into my other branches, I mess with my branch's history, and add all the unrelated features' commits to it.

Maybe I should branch more, by the subtask, adding a third level like this:

        \                       /         \
            \                 /             \  
             \-feature11-c-c-c          feature12-c-c-c..

This leaves unaddressed the fact that sometimes a feature is bigger than what a branch should be.

These are my thoughts on the matter so far, so I'm very open to suggestions on what's the best git workflow on one or two person teams.

I hope the diagrams are easy to follow.


2 Answers 2


TL;DR: your git workflow isn't really the problem. The problem is that you need more, smaller iterations on the features you put in your topical branches. This will reduce the pain of keeping these topical branches up-to-date and integrating them into the upstream.

You definitely want to keep unmerged branches up-to-date with the changes in their upstream, and rebasing is generally the correct way to do this.

Your comment that "sometimes a feature is bigger than what a branch should be" leads me to believe that you have long-running topical branches that you find difficult to integrate with your integration branch. This, in my experience, is the actual root of your pain.

Imagine if your topical branches lasted a few hours and then were merged back in to the integration branch. These ephemeral branches are likely to be trivial to keep up-to-date and trivial to merge back into your integration branch. On the other hand, imagine a long-running topical branch that spans multiple releases of the software without integration. It would probably be quite difficult to integrate. This should lead you to conclude that short-running topical branches that are frequently rebased against master are easier to work with.

The question, then, becomes "why would features be bigger than what a branch should be?" This is probably because you're trying to do too much at once. The best way to keep topical branches short-lived and to make integration painless is to work in an iterative fashion where the minimum marketable feature is ruthlessly hewn down to its bare essentials and further work on that feature is added on in separate increments.

  • +1, not even your answer's great, but your deductions of my workflow are almost flawless. The only wrong is that I'm not actually finding difficult anything, it's not such a complex project yet, and there's few to no conflict's so far, and since I do those merging master into the branches, everything keeps quite up to date. My problem is that then the topical history gets dirty with the commits from other branches. I could even actually bring diff branch..master and apply that. Jun 17, 2011 at 3:51

If you're the only developer, why make it so complicated? Have a single master branch, commit changes locally, and only push when you are sure the code is working. If you try to implement a feature and it doesn't work out, just revert back to the commit before you tried to implement it.

  • He is the only developer to push to master. Not that he is the only one in the team. Jun 17, 2011 at 2:02
  • 2
    And yes, even if he was the only one, he should have a well defined workflow to keep a decent track of changes and also to be able to increase the team if needed without the solo-developer having to push things to master to make things work so that the new developer can begin his work... Jun 17, 2011 at 2:06
  • 1
    sorry, man, newbie as I might be, I have to downvote this answer Jun 17, 2011 at 3:46
  • 2
    @Felipe, he said he was the only programmer. @Lacrymology, even if you keep more than one branch, it pays to keep things simple. Having a lot of branches will just confuse you in the end.
    – Zhehao Mao
    Jun 17, 2011 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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