Always keep in mind that git cherry-pick creates “duplicate” commits and that you should clean up afterwards. Cherry picking should be reserved for cases when a git merge or git rebase is not possible, when you want to move only individual commits from one branch to another. Whenever you can use a traditional merge or rebase, you should do so. In case you’re using a GUI app like Tower, this is what the whole process looks like: A tool for special cases, not the everyday integration HEAD is now at 776f8ca Change about title and delete error page Now, in order to clean up and undo the commit, you can use git reset. This means that cherry picking doesn’t “move” a picked commit from the original branch it merely creates a copy and leaves the original untouched. If you check the master branch, you can still see that “wrong” commit. And what about the original commit? Cleaning up the other branch It is, however, a completely new commit with its own, new ID. What happened in the background? Git created a copy of the commit with the same changes and the same commit message on the feature/newsletter branch. If you run git log again, you can see the new commit on the feature/newsletter branch: $ git logĬommit 7fb55d06a8e70fdce46921a8a3d3a9de7f7fb8d7 (HEAD -> feature/newsletter) Newsletter signup pageġ file changed, 0 insertions(+), 0 deletions(-) First, you switch branches, and then you cherry pick the commit: $ git checkout feature/newsletter Let’s cherry pick that particular commit and move it to the correct branch. So, the commit with the ID 26bf1b48 ended up in master, but you should’ve committed it to the branch feature/newsletter. The following screenshot of Tower, a graphical Git client for macOS and Windows, shows the problem and the commit 26bf1b48 which was accidentally made on the master branch:Īlternatively, you can examine the situation on the command line if you type git log in the terminal: $ git logĬommit 26bf1b4808ba9783e4fabb19ec81e7a4c8160194 (HEAD -> master) What now? Do you have to call your team members or your boss to explain this “mistake”? Let’s say you committed something to the master branch that was intended for the feature/newsletter instead. Here’s a real-life scenario to explain when cherry picking is the right approach. Cherry picking is meant for special occasions, not as a replacement for merging and rebasing. Your primary goal should be to work on a branch level, and both git merge and git rebase were built exactly for this job. Part 8: Using the Reflog to Restore Lost Commitsīefore we look at a practical example, a word of warning: don’t get too excited about cherry picking.Part 7: Cherry-Picking Commits in Git ( You are here!).Part 3: Better Collaboration With Pull Requests.Part 1: Creating the Perfect Commit in Git.Using cherry-pick this is not a big problem: you can switch to the correct branch and then cherry pick the commit! Let’s say you accidentally made a commit on the wrong branch. So why would you want to do this and pick only one commit from a branch to apply it to another one? There are different reasons, of course, but an especially helpful one is to undo changes. This is a big difference compared to git merge or git rebase, which both integrate all new commits from the specified branch. Today, we’ll look at git cherry-pick and how it allows us to integrate selected, individual commits from any branch into our current HEAD branch. Although there are a couple of differences between git merge and git rebase, both commands have the same goal: they integrate changes from one branch into another. In part 5 of this series, we looked at rebasing and merging. Be sure to follow us on Twitter or sign up for our newsletter to hear about the next articles! This article is part of our “Advanced Git” series.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |