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?

  • How can I rebase 2 topic branches onto a new branch?
  • Commit to another branch without touching unstaged files
  • Execute commands from .bat file on Git Bash Terminal
  • Using a git subrepo which has ANOTHER git subrepo in a mercurial repository, is this possible?
  • git force file line ending on commit
  • Git clone with custom SSH using GIT_SSH error
  • Git: How to prevent the local machine username from being posted?
  • Workflow for maintaining different versions of codebase for different versions of Python
  • Cannot build with TeamCity and one git submodule
  • Best practices for cross platform git config?
  • How to use eclipse project from github for Android development
  • Android Studio Git .gitignore vs Project > Settings > Version Control > Ignored Files
  • 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 git branch.

    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.

    Git Baby is a git and github fan, let's start git clone.