I have two branches. Commit a is the head of one, while the other has b, c, d, e and f on top of a. I want to move c, d, e and f to first branch without commit b. Using cherry pick it is easy: checkout first branch cherry-pick one by one c to f and rebase second branch onto first. But is there any way to cherry-pick all c-f in one command?
Here is a visual description of the scenario (thanks JJD):
Git 1.7.2 introduced the ability to cherry pick a range of commits. From the release notes:
git cherry-picklearned to pick a range of commits (e.g.cherry-pick A..Bandcherry-pick --stdin), so didgit revert; these do not support the nicer sequencing controlrebase [-i]has, though.
To cherry-pick all the commits from commit A to commit B (where A is older than B), run:
git cherry-pick A^..B
If you want to ignore A itself, run:
git cherry-pick A..B
Notes from comments:
A should be older than B, or A should be from another branch.A^^..B as the caret needs to be escaped, or it should be "A^..B" (double quotes).zsh shell, it should be 'A^..B' (single quotes) as the caret is a special character.(Credits to damian, J. B. Rainsberger, sschaef, Neptilo, Pete and TMin in the comments.)
If you have selective revisions to merge, say A, C, F, J from A,B,C,D,E,F,G,H,I,J commits, simply use the below command:
git cherry-pick A C F J
The simplest way to do this is with the onto option to rebase. Suppose that the branch which current finishes at a is called mybranch and this is the branch that you want to move c-f onto.
# checkout mybranch
git checkout mybranch
# reset it to f (currently includes a)
git reset --hard f
# rebase every commit after b and transplant it onto a
git rebase --onto a b
...onto your currently-checked-out branch:
commitgit cherry-pick commit
Examples:
git cherry-pick my_branch # by branch name
git cherry-pick 1e038f108a130831f108329b1083a8139813fabc # by full hash
git cherry-pick 1e038f10 # by partial hash
Note that you can cherry-pick any number of commit hashes at once, and in any order you want. They will simply be applied one-at-a-time, and in the order you specify. If any conflicts arise, you will have to resolve them one-at-a-time then use git add my_file then git cherry-pick --continue when done to continue the cherry-pick process.
git cherry-pick commit1 commit2 commit3 commit4 commit5
I originally learned the basics of this style from the most-upvoted answer by @Eric Darchis here.
Notice that to cherry-pick a range of commits, you must specify a starting and ending commit hash, with .. between them. However, in a range of commits, the beginning commit is NOT included. Therefore, to include it, you must specify the commit before the beginning commit. The syntax to specify the preceding commit is to put ~, ~1, or ^ right after your commit, as in: beginning_commit~, which means: "the commit right before beginning_commit".
# A. INCLUDING the beginning_commit
git cherry-pick beginning_commit~..ending_commit
# OR (same as above)
git cherry-pick beginning_commit~1..ending_commit
# OR (same as above)
git cherry-pick beginning_commit^..ending_commit
# B. NOT including the beginning_commit
git cherry-pick beginning_commit..ending_commit
Note: commit~, commit~1, and commit^ all mean "one commit prior to commit", or otherwise said: "the commit before commit".
To specify two commits prior to commit, you can use syntax like this:
commit~~
commit~2 # my preferred syntax
commit^^
To specify three commits prior to commit, you can do this:
commit~~~
commit~3 # my preferred syntax
commit^^^
This does NOT work:
commit^3 # INVALID syntax
To test the above "previous commit syntax" concepts yourself, the easiest way is with the git log command. Ex:
git log commit
git log commit~
git log commit~1
git log commit^
git log commit~~
git log commit~5
# etc.
...when their branch peer_branch is forked off of an earlier version of your branch my_branch.
# you cherry-pick all of their extra commits from their `peer_branch` onto
# your `my_branch` (note: the 3 dots below are very important!)
git fetch origin peer_branch # get their latest changes from the remote
git checkout my_branch # ensure you're on your branch
# cherry-pick their range of commits
git cherry-pick my_branch...origin/peer_branch
git log # review the commits you just chery-picked
git push # push your changes to the remote
Let's say you are working on your feature branch my_branch, and your peer wants to help make some changes for you to help you on your feature. You have already pushed my_branch to the remote named origin. So, they are going to fetch your remote branch named my_branch to their local computer, fork their own branch named peer_brach off of it, then push to their own branch named peer_branch. Once they do that, you will cherry-pick all of their additions at once. This is what the first part of this process looks like:
# **your peer** does this
# peer fetches your branch named `my_branch` and forks their `peer_branch`
# off of it
# they fetch your latest work from remote `my_branch` into their locally-stored
# remote-tracking "hidden" branch named `origin/my_branch`
# (note: you can see all locally-stored remote-tracking "hidden" branches
# with `git branch -r`)
git fetch origin my_branch
# create `peer_branch` as a fork off of `origin/my_branch`, and check it out
git checkout -b peer_branch origin/my_branch
# Now they can add their changes and commits and `git push` to remote `origin`
# as their own `peer_branch` when done.
Now that they have pushed all of their changes to remote origin as their own branch named peer_branch, you can cherry-pick all of their commits they added on top of your work like this:
# **you** do this to cherry-pick your peer's helpful changes they added to
# your work
# you fetch their latest work from their branch named `peer_branch` on remote
# `origin` into your locally-stored remote-tracking "hidden" branch named
# `origin/peer_branch`
# (note: you can see all locally-stored remote-tracking "hidden" branches
# with `git branch -r`)
git fetch origin peer_branch
# ensure you are on `my_branch` (if you aren't already)
git checkout my_branch
# you cherry-pick all of their extra commits from their `peer_branch` onto
# your `my_branch` (note: the 3 dots here are very important!)
git cherry-pick my_branch...origin/peer_branch
git log # review the commits you just chery-picked
git push # push your changes to the remote
For your understanding, that cherry-pick command just above, with 3 dots in it, is exactly equivalent to this longer command:
git cherry-pick $(git merge-base my_branch origin/peer_branch)..origin/peer_branch
The git merge-base my_branch origin/peer_branch part finds the common parent commit hash between branch my_branch and branch origin/peer_branch. This is the commit at which point they forked their peer_branch off your your my_branch. Then, you are, of course, cherry-picking the range of commits from that point to (..) their final commit at origin/peer_branch.
To read more about that 3-dot syntax, see here: What are the differences between double-dot ".." and triple-dot "..." in Git diff commit ranges? [duplicate]. For help on git checkout -b new_branch from_branch, see my answer here: Various ways to create a branch in git from another branch
...) vs 2 dot range syntax, ^commit ("not" commit), commit^ (the parent of commit), etc.git rebase is just a bunch of sequential git cherry-picks. See my other answer here (Who is "us" and who is "them" according to Git?) where I show, among other things, an ASCII drawing I made of how a git rebase works and what it's doing.
Or the requested one-liner:
git rebase --onto a b f
You can use a serial combination of git rebase and git branch to apply a group of commits onto another branch. As already posted by wolfc the first command actually copies the commits. However, the change is not visible until you add a branch name to the top most commit of the group.
Please open the picture in a new tab ...
To summarize the commands in text form:
gitk --all &.git rebase --onto a b f.HEAD is marked.git branch selectionThis should clarify things:
a is the new root destination of the group.b is the commit before the first commit of the group (exclusive).f is the last commit of the group (inclusive).Afterwards, you could use git checkout feature && git reset --hard b to delete the commits c till f from the feature branch.
In addition to this answer, I wrote a blog post which describes the commands in another scenario which should help to generally use it.
To apply J. B. Rainsberger and sschaef's comments to specifically answer the question... To use a cherry-pick range on this example:
git checkout a
git cherry-pick b..f
or
git checkout a
git cherry-pick c^..f
To cherry pick from a commit id up to the tip of the branch, you can use:
git cherry-pick commit_id^..branch_name
git rev-list --reverse b..f | xargs -n 1 git cherry-pick
git rev-listprints all revisions from branchbtof(reversed) so that when each line (the commit hash) is passed in order, it will cherry pick each one onto the current gitHEAD. i.e.git cherry-pick {hash of c}; git cherry-pick {hash of d}; ...
Another variant worth mentioning is that if you want the last n commits from a branch, the ~ syntax can be useful:
git cherry-pick some-branch~4..some-branch
In this case, the above command would pick the last 4 commits from a branch called some-branch (though you could also use a commit hash in place of a branch name)
Cherry-pick multiple commits:
Checkout to your branch where you want to cherry-pick the commits
Use this command: (by partial hash)
git cherry-pick 1e038f10 1e038f11 1e038f12 ...
Actually, the simplest way to do it could be to:
MERGE_BASE=$(git merge-base branch-a branch-b)rebase the resulting branch onto itself, starting at the merge base from step 1, and manually remove commits that are not desired:
git rebase ${SAVED_MERGE_BASE} -i
Alternatively, if there are only a few new commits, skip step 1, and simply use
git rebase HEAD^^^^^^^ -i
in the first step, using enough ^ to move past the merge-base.
You will see something like this in the interactive rebase:
pick 3139276 commit a
pick c1b421d commit b
pick 7204ee5 commit c
pick 6ae9419 commit d
pick 0152077 commit e
pick 2656623 commit f
Then remove lines b (and any others you want)
I need cherry pick a commit from one branch to another on priority, but commits here were difficult to understand, hope below helps with a easy one:
Procedure to do below:
1 . Get commit details from "dev" branch
// Go to "dev" branch
git checkout dev
// Get the commit id (1e2e3e4e1 here)
git log --oneline
> ...
> ...
> 1e2e3e4e1 Remove Last Name field
> ...
> ...
2 . Push the commit to "hotfix1" branch
// Go to "hotfix1" branch
git checkout hotfix1
// Get the commit (1e2e3e4e1) from "dev" branch to "hotfix1" branch
git cherry-pick 1e2e3e4e1
// verify changes are correct
gitk
// push to "hotfix1" branch
git push
To do multiple at once, only 1 change in the above, give all commit ids in sequence:
git cherry-pick 1e2e3e4e1 1e2e3e4e2 1e2e3e4e3
Here's a script that will allow you to cherry-pick multiple commits in a row simply by telling the script which source and target branches for the cherry picks and the number of commits:
https://gist.github.com/nickboldt/99ac1dc4eb4c9ff003a1effef2eb2d81
To cherry-pick from your branch to master (uses the current branch as source):
./gcpl.sh -m
To cherry-pick the latest 5 commits from your 6.19.x branch to master:
./gcpl.sh -c 5 -s 6.19.x -t master
Alternatively using GitHub Desktop Application,
You can multi-select commits in the history tab of the source branch, then right-click to get the option "Cherry-Pick Selected Commits".
In addition to commit-ish, you can pipe in a list of SHAs from stdin.
git rev-list --reverse ..main -- path/ | git cherry-pick --stdin
rev-list is basically the plumbing command (the "ugly" but fast cousin) of git-log
NB that --reverse is needed.
You can do more advanced stuff this way rather than simply a commit range.
git format-patch --full-index --binary --stdout range... | git am -3
