How can I create a feature branch from code changes in my development branch that I haven't checked in?

Question

I have a bunch of changes in my development branch that I would like to create a new feature branch for. Can I do:

//switch to branch
git checkout -b uploadFeature develop

//push my changes to the feature branch (do this many times)
git push origin uploadFeature

//merge the feature branch into the master
git checkout develop
git merge --no-ff uploadFeature

Is that the right workflow? Is there anything else I need to be worried about? What happens if other people on my team are checking into the master, do I need to pull changes from the master into the feature branch every day?

Answer 1

Your merge command won't work because you need to reset develop back to origin/develop.

Assuming your history looks something like this (before your merge commands):

C (develop, uploadFeature, HEAD)
|
B
|
A (origin/develop)

And you want commits B and C to show that they were done in a feature branch instead of directly on develop.

You need to do this before your merge:

git reset --hard origin/develop

Which will make your history look like:

C (uploadFeature)
|
B
|
A (develop, HEAD, origin/develop)

Then you can do your merge command and the history will look like this:

D (develop, HEAD)
|\
| \
| C (uploadFeature)
| |
| B
| /
|/
A (origin/develop)

---

As to all of your other questions most of them depend on your workflow.

Answer 2

So you're currently on develop , with un-committed working copy changes against the HEAD commit.

$ git checkout -b feature

will create a branch called feature , starting from the same HEAD commit, and switch you onto it. Your working copy doesn't change

$ git add {any new files}
$ git commit

will create a local commit on feature with your new changes. The develop branch hasn't changed, and feature is now one commit ahead of develop .

$ git push -u origin feature

will create a remote branch called feature, push your commit to it, and update your local branch to track the remote one.

Your merge is fine, although I'm not sure why you're prohibiting fast-forward.

---

What happens if other people on my team are checking into the master, do I need to pull changes from the master into the feature branch every day?

not unless their changes affect yours.

Typically, I'd suggest doing the simple merge as above - if it fails , then merge develop into feature , fix any conflicts and re-test on the feature branch, and then re-do the original merge.

Answer 3

that workflow looks alright. If you or ther people pushes into master, then there will be divergence, and you will have to merge the changes, git makes merging changes relatively easy, especially if you use small commits.

It is not necessary to pull changes everyday, but small merges will let you detect incompatible changes early on instead of when you do the large merge; if your feature branch will be very long lived, it's often wise to regularly merge from master, for short lived feature branch, that isn't usually necessary.

Some teams do a rebase instead of merging, so that you finish with a cleaner history and make it more likely that other people that are only working on master to be able to do fast forward merge.