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.
develop is a local branch that probably tracks origin/develop, your remote tracking branch.
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.
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.
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.
