The command git cherry-pick commit applies the changes introduced by the named commit on the current branch. It will introduce a new, distinct commit. Strictly speaking, using git cherry-pick doesn’t alter the existing history within a repository; instead, it adds to the history.

As with other Git operations that introduce changes via the process of applying a diff, you may need to resolve conflicts to fully apply the changes from the given commit.

The command git cherry-pick is typically used to introduce particular commits from one branch within a repository onto a different branch. A common use is to forward- or back-port commits from a maintenance branch to a development branch.

In Figure 10-4, the dev branch has normal development, while the rel_2.3 contains commits for the maintenance of release 2.3.

Figure 10-4. Before git cherry-pick of one commit

During the course of normal development, a bug is fixed on the development line with commit F. If that bug turns out to be present in the 2.3 release also, the bug fix, F, can be made to the rel_2.3 branch using git cherry-pick:

$ git checkout rel_2.3

$ git cherry-pick dev~2      # commit F, above

After cherry-pick, the graph resembles Figure 10-5.

Figure 10-5. After git cherry-pick of one commit

In Figure 10-5, commit F' is substantially similar to commit F, but it is a new commit and will have to be adjusted—perhaps with conflict resolutions—to account for its application to commit Z rather than commit E. None of the commits following F are applied after F'; only the named commit is picked and applied.

Another common use for cherry-pick is to rebuild a series of commits by selectively picking a batch from one branch and introducing it onto a new branch.

Suppose you had a series of commits on your development branch, my_dev, as shown in Figure 10-6, and you wanted to introduce them onto the master branch but in a substantially different order.

Figure 10-6. Before git cherry-pick shuffle

To apply them on the master branch in the order Y, W, X, Z, you could use the following commands:

$ git checkout master
$ git cherry-pick my_dev^     # Y
$ git cherry-pick my_dev~3    # W
$ git cherry-pick my_dev~2    # X
$ git cherry-pick my_dev      # Z

Afterward, your commit history would look something like Figure 10-7.

Figure 10-7. After git cherry-pick shuffle

In situations like this, where the order of commits undergoes fairly volatile changes, it is quite likely that you will have to resolve conflicts. It depends entirely upon the relationship between the commits. If they are highly coupled and change overlapping lines, you will have conflicts that need to be resolved. If they are highly independent, you will be able to move them around quite readily.