Git Branch Workflow Dilemma
From master, I created a branch A because I wanted to add a new feature. Upon finishing the feature, I committed everything up to this point. But then I kept working on the branch, and now realize all things I have done since that commit would make more logical sense in a new branch, call it B, off of master.
Now, I can obviously commit my changes to A, pull it into master, then branch master, call it B, and continue on. But what if I really want to keep things clean and would rather pull my last commit from A into master, then create a branch B, then pull in my uncommitted changes that I have in A right now?
2 Solutions collect form web for “Git Branch Workflow Dilemma”
Starting from what you have in branch A:
git stash # save your changes away git checkout master # check out the master branch git merge A # merge your changes from branch A git pull --rebase # This is to get rid of the 'Merged branch A' log entry git checkout -b B # create and checkout branch B from current master git stash pop # get back the changes you saved
and you will be in your newly created branch B with your uncommited changes.
You can merge and create branches from arbitrary starting points, not just the HEAD of a certain branch.
Take a look at the options related to
<start-point> in the docs for
As for merging A into master at the point where you actually started working on B, the
git merge command accepts any commit as an argument (again, not just the HEAD of a branch). Go back into the logs of this branch, find the commit ID of the point where work on A finished and you started working on feature B, checkout master, and then merge with this ID.