git’s main differences when compared to other version control systems is that it lets the user rewrite the history. The main way to do this is to use
git rebase, usually followed by a
force to overwrite history the remote with the local history.
Here’s a look at how to split existing commits using
Table of Contents
Say you have two files edited in a commit (A and B) and you would like to get the changes from one of those files (A) into your current branch but not those from the other (B).
git cherry-pick <commit-hash> is not an option since it would pull in the changes for both A and B.
The solution is to split the commit into 2 and only cherry-pick the new commit that contains changes for A.
To do this:
git rebase -i <commit-hash>~(note the
git rebase -i <hash-of-previous-commit>
- find the commit you want to split in the rebase edit screen, change the
- save and exit (
:wqto close VIM)
git reset HEAD~to reset the staged changes
git add [files-to-add]all the files we want to add to the first commit (here would be
git add A)
git commitnormally, with a message etc
- Run as many other rounds of as you want commits:
git add [other-files-to-add]
continueto indicate that the splitting has been finished and to continue the rebase
Finally we can
git cherry-pick <new-commit-hash> to get the changes into our branch
For any questions about using git, feel free to comment below or tweet to me @hugo__df.
Pre-order discount on The Jest Handbook