tags:

views:

35

answers:

1

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

http://nvie.com/git-model

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.

+1  A: 

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.

poke
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
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
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
Hmm. Then I guess I should read that article a bit more detailed ^^
poke
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
Ah excellent, thanks for all the good comments too guys. I've always been a pretty straight shooter w/ git, IE I've never gotten too fancy with branching and what not, so good feedback.
gct