27 | Cherry-Picking Commits |
You sometimes need to grab one commit from another branch and merge it into your local branch, such as a bug fix that needs to be backported. You can grab commits one at a time using git cherry-pick.
Cherry-picking a commit from another takes that single commit and commits it to your local branch. It’s pretty straightforward and appears extremely useful in a lot of situations, but be careful.
Cherry-picked commits have different commit IDs than the original commit they came from because their parent changed—remember that a commit ID is based partially on where it exists in the history, and changing the parent changes the commit ID. A good rule of thumb is to cherry-pick commits only when a merge is not an option, in other words, backporting a bug fix where the backported change is never going to be merged forward.
You must specify the commit that you want to cherry-pick. You can do this with either a commit ID, a branch name, a tag, or some relative reference to any of these. Keep in mind that using a branch name or tag means that the latest commit that those reference is cherry-picked in, not the entire history.
Normally git cherry-pick automatically creates a new commit as soon as it is done. You can change this behavior with two different options. Use --edit (or -e) to launch the editor and change the commit message before committing the cherry-picked revision. This allows you to edit the commit message but not the actual commit.
You can use --no-commit (or -n) to tell Git to stop as soon as the change has been merged and staged. You can use this to cherry-pick several commits and then commit them into your local branch as one commit. Remember to start with the oldest commit first when cherry-picking more than one commit; otherwise, you might end up trying to make a change that isn’t possible or having conflicts because it is in the wrong order.
You can also add a Signed-off-by line to the end of a cherry-picked commit. Signed-off lines consist of the phrase Signed-off-by: followed by your name and email address (pulled from the configuration). This is useful for creating a chain of review for commits and can become essential in backported commits to ensure they have been properly reviewed prior to being merged into an existing branch.
What To Do... |
| prompt> git cherry-pick some commit ID |
some commit ID refers to a commit any way you normally can: an actual commit ID, branch name, tag, or some relative version of any of those. For example, to cherry-pick the latest from release_1.0 or commit a74cc83, use this:
| prompt> git cherry-pick release_1.0 |
| Finished one cherry-pick. |
| [master bcdbca8] add <meta> tags |
| 1 files changed, 1 insertions(+), 0 deletions(-) |
| prompt> git cherry-pick a74cc83 |
| Finished one cherry-pick. |
| [master dd94f18] working on conerting to Textile |
| Author: Andy Lester <[email protected]> |
| 5 files changed, 195 insertions(+), 176 deletions(-) |
| rewrite crank (81%) |
| create mode 100644 s/index.textile |
| create mode 100644 s/java.textile |
| prompt> git cherry-pick --edit release_1.0 |
| ... or ... |
| prompt> git cherry-pick -e release_1.0 |
| prompt> git cherry-pick --no-commit release_1.0 |
| ... or ... |
| prompt> git cherry-pick -n release_1.0 |
| prompt> git cherry-pick --signoff release_1.0 |
| ... or ... |
| prompt> git cherry-pick -s release_1.0 |
Task 7, Committing Changes
Task 15, Merging Commits Between Branches
3.15.12.34