This is how I roll with git:

  1. I clone/fork something locally
  2. I create a new branch devel. This is supposed to be a quickfix branch. It is also supposed to be parent to all branches.
  3. I create a topic branch (say make a new theme lex)

I actually create a few more child-topic-branches (say lex.th2) to test/see different things.

But so now, I have to quickfix (in devel) a core functionality (say re-correct database credentials in wp-config).
I then have to switch to lex and merge devel. And then to lex.th2 and merge lex. (So that changes from devel could goto lex and to lex.th2)

Doing all this severely messes up my history-graphs

C:\Program Files (x86)\Git\bin\wish.exe

I'll admit that the "official" workflow was too much for me and I just took the parts that I liked from it... probably badly. So any suggestions how to make it "tidy" while still not complicating or deviating too much?


You should learn the rebase command and (and how to do it interactively). I do it because it lets me keep all the changes in a straight revision graph instead of a tangled mess.

So whenever I have a hotfix I usually commit that directly to the master branch. Whenever I work on a small feature, I commit that to the master branch. Before I push anything I do:

git pull --rebase

This fetches the latest changes on your master branch and rebases your changes with that. I don't really mind the merge conflicts as I like to take them head on while I know what I did.

If I ever need to rearrange my commits in situations where I did a bunch of hotfixes while finishing up a feature I do the interactive rebase command (i.e. do an interactive rebase of the master branch on top of the changes of the origin remote's master branch):

git rebase -i origin/master

It'll prompt a text file with a list of commits like this:

pick 1111111 Implemented feature #34
pick 2222222 Updated readme to feature #34
pick 3333333 FIX: something works now
# ... a bunch of commands listed below

The order of commits is from top to bottom. But I can rearrange these the way I want them:

# moved commit 3333333 first will be applied first in the 
pick 3333333 FIX: something works now

# I want feature #34 to be one commit so I do it like this:
pick 1111111 Implemented feature #34
squash 2222222 Updated readme to feature #34
# squash will squash commits 1111111 2222222 to one commit 
# and prompt for a new commit message using both as template

Save and close and the rebase is performed according to the text file. This way git will keep it all nice and tidy the way you want it... in my case a long nice straight queue of changes to be pushed.

There are times when I create topic branches, but I do the same thing before merging it to master. I.e. rebase the changes on the topic branch with master and then interactively rebase it if I want to tidy it up.

It may seem like a bad thing to rewrite the history like this, but as long as you haven't pushed the changes you can do what you want with it. This is the reason why I rarely have a devel branch; your local master branch is already your devel branch. As long as you haven't pushed anything it is only available at your repository.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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