fbpx
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

How To: Move Git Commits From One Branch to Another

windchill features best plm software
Written by SPK Blog Post
Published on April 11, 2018

Git encourages developers to use branches during their development process as a means of coordinating and managing changes to the master branch. Git does not force any particular strategy for doing so and consequently, several popular branching strategies have emerged.

Regardless of the of branching strategy used, you may find yourself in a situation where you’ve committed work on “Branch A” but then wish you had done the work on “Branch B” instead. This could be because you combined work for two different features on the same feature branch or perhaps you were working directly on master without realizing it and you need to transfer your work to a development branch to conform to official process demands. Whatever the case may be, let’s look at how you can move a commit off one branch and onto another so that it no longer appears in the history of the original branch. We will look at how to move the commits to a new branch as well as moving them to an existing branch.

The process for moving work off one branch and onto a newly created branch is the simplest of the two operations.

  1. git checkout
  2. git branch
  3. git reset –hard HEAD~1

In step (1) we make sure that we are on our “source branch” – the branch that has the commits we want to move to a new branch. Step (2) creates a new branch that uses the source branch as its starting point. As a result, the new branch will have all the commits currently found in the source branch, including the changes we want moved. After we execute step (2), keep in mind that we are still on the source branch and did not switch to the new branch. In step (3) we delete the commit from the source branch. Using the “reset –hard” command allows us to revert the workspace back to the way it was at the specified commit. In the case of the example, we supply the shorthand “HEAD~1” which means “go back one commit from where HEAD is pointing”. Substituting a different number like “3” (HEAD~3) would jump things back 3 commits. Alternatively, you could supply an explicit commit SHA1 value and the workspace would revert back to that commit. Now we’ve reached our goal state in which the new branch has the target commit and the source branch does not – effectively “moving” it from one to the other.

If we want to move a commit to an existing branch, we can follow a similar process using merge.

  1. git checkout
  2. git merge
  3. git checkout
  4. git reset –hard HEAD~1

In step (1) we make sure we are on the branch where we want the commit to end up. We then merge in the source branch in step (2). At this point, our target branch should have the work we want transferred. We move back to the source branch in step (3) and, as previously, we delete the commit from the source branch in step (4).

David Hubbell
Senior Software Engineer
SPK and Associates

Latest White Papers

Related Resources

The Domino Effect of Late-Stage Product Changes

The Domino Effect of Late-Stage Product Changes

Introduction Welcome to this video from SPK and Associates. My name is Michael Roberts, VP of Sales and Marketing for SPK and Associates. Hi, I'm Chris McHale. I am co-founder and CEO of SPK and Associates, and we are an IT services company that focuses on...

The Case for Shifting BOM Management from ERP to PLM Systems

The Case for Shifting BOM Management from ERP to PLM Systems

Many companies are managing their BOMs in ERP rather than a PLM system due to the desire for better data reporting in the ERP. Although this is understandable, there are plenty of use cases for managing a BOM in a PLM system such as Windchill. Many businesses...