Git workflow - advise a newbie

Question

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:

              /feature2-c-c-c-c-m-c-c-c-c
             /                 /     \
master-----------------------m-p------m-p
        \                  /           \  
         \-feature1-c-c-c-c-c-c-c-c-c-c-m-c-c

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:

                 ....................\
master---------------------------m-p--m-p-....
        \                       /         \
         \-feature1------------m-----------m.....
            \                 /             \  
             \-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.

Answer 1

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.

Answer 2

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.