git flow branching model branching

Question

I've been reading and re-reading the post about a successful git model (git flow) and I'm confused about a couple things when working off a develop branch. He says:

When starting work on a new feature, branch off from the develop branch.

$ git checkout -b myfeature develop

1. What branch is he starting in? My checked out 'develop' branch?
2. Is the 'develop' after 'myfeature' track my local 'develop' branch or the remote 'origin/develop' branch?
3. If I start in my 'develop' branch when I create 'myfeature' do I need the 'develop' at the end?
4. Does 'myfeature' copy the current HEAD of the develop branch?
5. If I only wanted to see my changes on a dev server, do I need to merge into my local develop or remote develop?

I'm trying to wrap my head around it - off to re-read it again and find some screencasts based on this model.

Answer 1

1. Doesn't matter, because he explicitly set the base commit (develop). After the command is run, he'll be on the myfeature branch, regardless of what was checked out before.

2. develop is a local branch that probably tracks origin/develop, your remote tracking branch.

3. Nope. git checkout -b myfeature, without an explicit starting point, will create a new branch at your HEAD. If you're at the tip of the develop branch, myfeature will be based on develop.

4. Not exactly. myfeature references the same commit that the tip of develop references. Nothing is "copied". When you commit changes while myfeature is checked out, the myfeature tip will be updated to the new commits. develop will not change.

5. If you want to see your changes at a remote location, you need to push to the remote location. Just merging into a local branch won't do anything for the remote side.

   If you want to "finish" your feature, git-flow-style, I'm guessing you want the Incorporating a finished feature on develop section: Switch to develop, merge in myfeature, delete myfeature, and push the now-updated develop out to origin.

[e] More answers:

• If I branch from within develop, it's the same as doing; git checkout -b myfeature develop when not in develop?

The new branch starts from develop in both cases. (git branch works the same way, except it won't switch you to the new branch like git checkout -b does.)

• And to finish myfeature, I would checkout develop > git pull > git merge myfeature > git push origin (aka origin/develop)?

Roughly, though git push origin is not always "aka origin/develop". By default git push origin will push all the local branches that have the same name (or have been set up to track) the branches on origin. (You can change the default with the push.default config setting.) git push origin develop will push just your local develop branch to origin's develop branch, which is what you want.

• If I don't pull before the merge, I run the risk of overwriting new commits made by others, correct?

Only if you force the push (which, seriously, don't do that). You can do the pull after the merge, but then you'd essentially be merging twice. It works out better to do the pull first, but you're not at risk of losing data if you don't.

• Is there ever a time when I would merge develop into myfeature?

Sure, if someone else has pushed out updates to origin/develop and you want to incorporate their changes. Essentially, you would merge develop into myfeature if you want to keep your feature branch current and you're not ready to merge into develop.

• And does myfeature every get merged into a release branch or should it always go back into develop?

In the git-flow system, myfeature should always go back to develop, and release branches always start from develop. develop is supposed to be the branch for changes ready for external exposure--for integration testing, release candidates, whatever--as well as the branch that represents the current state of development in the project. It's the starting point for all the new stuff. You don't want to end up with your work in the myfeature branch and some random release branch, but not the main develop line.

Answer 2

It doesn't matter what branch you're currently on when you use an explicit start-point. The syntax is:

git branch <branchname> [<start-point>]

If you don't specify a start-point, git will branch off whatever branch you're currently on. However, with an explicit start-point, you can create the new branch off any head listed in .git/refs/heads.

As for the rest:

• Develop should be a tracking branch for origin/develop.
• Your new feature branch will initially look like a synonym for develop when you visualize the history, because the commit reference pointers are identical until you make some commits.
• List item 5 is out of scope for your current question. Ask another. :)

Answer 3

Coming in very late here, but you should consider the possibility that the model you have referenced is considered by many to be bad practice. See this blog post.

This gist of it is that, whilst you can use GIT for a branching model that is akin to a non-distributed version control system, that doesn't mean you should. If you plan to do so, ask yourself, should I have chosen GIT in the first place. The merging with no fast-forwards is especially criticised as robbing you of many the advantages/tools that GIT offers.

I have no opinion yet. I'm just digesting all this stuff myself.