Take the 2-minute tour ×

I'm looking to rewrite my git repo to use a new branching model I came across:


But right now all my history lives in the master branch. I'd like to rewrite it (possible using git-filter-branch?) So that all that history is in a branch called development now.
Is this possible? It's definitely beyond my limited git skills.

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Just create a development branch, pointing to the master's HEAD, and then you can delete the master branch.

Btw. from the first look at that branching model, I don't think it was made while really thinking of git's branching techniques. Because it interprets branches as steady development lines which is true for other VCSystems like SVN, but not for git. Branches in git are just pointers to commits, and you can move them around as much as you want.

share|improve this answer
Or even git branch -m master development. But you're right, that's a weird-looking workflow. It mostly makes sense except the master "branch", which somehow never merges from develop yet manages to increment version numbers. If you take off master, rename develop back to master, and tag the versioned releases, it'd be a little more reasonable. –  Jefromi Mar 27 '10 at 19:49
Oops, my previous comment was misinformed - the full workflow is not actually shown in the main diagram at the top. It's actually a fairly traditional git workflow, with topic branches (features, bugfixes) branching off, then being merged upwards, and the stable branch periodically moving up when development is considered stable. It looks like a good workflow - but the OP probably needs to understand a bit more about what branches mean before trying to follow it. –  Jefromi Mar 27 '10 at 20:00
With respect to your comment that "you can move [branches] around as much as you want" - if by move you mean commit to and merge into, then yes. You don't want to actually move (i.e. non-fast-forward changes) them though. The branching model is really quite git-ish: it has many transient branches for final release integration, feature development, and bugfixes. The main branches remain stable so that users know what to pull: a stable release from master or a nightly build from develop. –  Jefromi Mar 27 '10 at 20:03
Hmm. Then I guess I should read that article a bit more detailed ^^ –  poke Mar 27 '10 at 20:03
by moving around much I meant that when merging (or fast-forwarding) a branch, all those commits would move to the new target branch, so in the end the result would look more linear and less split into the branches. –  poke Mar 27 '10 at 20:05

Your Answer


