Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
Here is an article by Vincent Driessen named A successful Git branching model which has some pretty good git guidelines and is, at least, worth reading. –  Felipe Sabino Jun 17 '11 at 2:01
... and check out gitflow: github.com/nvie/gitflow –  AaL Nov 21 '13 at 11:27
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
+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. –  Lacrymology Jun 17 '11 at 3:51
add comment

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.

share|improve this answer
He is the only developer to push to master. Not that he is the only one in the team. –  Felipe Sabino Jun 17 '11 at 2:02
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... –  Felipe Sabino Jun 17 '11 at 2:06
sorry, man, newbie as I might be, I have to downvote this answer –  Lacrymology Jun 17 '11 at 3:46
@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 '11 at 12:17
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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