How to cherry pick a range of commits and merge into another branch

I have the following repository layout:

  • master branch (production)
  • integration
  • working

What I want to achieve is to cherry pick a range of commits from the working branch and merge it into the integration branch. I pretty new to git and I can’t figure out how to exactly do this (the cherry picking of commit ranges in one operation not the merging) without messing the repository up. Any pointers or thoughts on this? Thanks!

  • Git submodule untracked after merge of “previous” branch
  • Git - Log commits of dev except which are cherry-picked into main
  • Tortoise Git - lost commits after a pull resulted in conflicts
  • GIT Customer Merge Driver Problems(Windows msysgit 1.9.0)
  • GIT warning: too many files skipping inexact rename detection
  • Merge two commits where commits are between
  • git merge to a branch without changes and commit
  • How to do blame across two different repositoies?
  • 7 Solutions collect form web for “How to cherry pick a range of commits and merge into another branch”

    When it comes to a range of commits, cherry-picking is was not practical.

    As mentioned below by Keith Kim, Git 1.7.2+ introduced the ability to cherry-pick a range of commits (but you still need to be aware of the consequence of cherry-picking for future merge)

    git cherry-pick” learned to pick a range of commits
    (e.g. “cherry-pick A..B” and “cherry-pick --stdin“), so did “git revert“; these do not support the nicer sequencing control “rebase [-i]” has, though.

    damian comments and warns us:

    In the “cherry-pick A..B” form, A should be older than B.
    If they’re the wrong order the command will silently fail.

    If you want to pick the range B through D (inclusive) that would be B^..D.
    See “Git create branch from range of previous commits?” as an illustration.

    As Jubobs mentions in the comments:

    This assumes that B is not a root commit; you’ll get an “unknown revision” error otherwise.

    Note: as of Git 2.9.x/2.10 (Q3 2016), you can cherry-pick a range of commit directly on an orphan branch (empty head): see “How to make existing branch an orphan in git”.

    Original answer (January 2010)

    A rebase --onto would be better, where you replay the given range of commit on top of your integration branch, as Charles Bailey described here.
    (also, look for “Here is how you would transplant a topic branch based on one branch to another” in the git rebase man page, to see a pratical example of git rebase --onto)

    If your current branch is integration:

    # Checkout a new temporary branch at the current location
    git checkout -b tmp
    # Move the integration branch to the head of the new patchset
    git branch -f integration last_SHA-1_of_working_branch_range
    # Rebase the patchset onto tmp, the old location of integration
    git rebase --onto tmp first_SHA-1_of_working_branch_range~1 integration

    That will replay everything between:

    • after the parent of first_SHA-1_of_working_branch_range (hence the ~1): the first commit you want to replay
    • up to “integration” (which points to the last commit you want to replay, from the working branch)

    to “tmp” (which points to where integration was pointing before)

    If there is any conflict when one of those commits is replayed:

    • either solve it and run “git rebase --continue“.
    • or skip this patch, and instead run “git rebase --skip
    • or cancel the all thing with a “git rebase --abort” (and put back the integration branch on the tmp branch)

    After that rebase --onto, integration will be back at the last commit of the integration branch (that is “tmp” branch + all the replayed commits)

    With cherry-picking or rebase --onto, do not forget it has consequences on subsequent merges, as described here.

    A pure “cherry-pick” solution is discussed here, and would involve something like:

    If you want to use a patch approach then “git format-patch|git am” and “git cherry” are your options.
    Currently, git cherry-pick accepts only a single commit, but if you want to pick the range B through D that would be B^..D in git lingo, so

    git rev-list --reverse --topo-order B^..D | while read rev 
      git cherry-pick $rev || break 

    But anyway, when you need to “replay” a range of commits, the word “replay” should push you to use the “rebase” feature of Git.

    As of git v1.7.2 cherry pick can accept a range of commits:

    git cherry-pick learned to pick a range of commits (e.g. cherry-pick A..B and cherry-pick --stdin), so did git revert; these do not support the nicer sequencing control rebase [-i] has, though.

    Are you sure you don’t want to actually merge the branches? If the working branch has some recent commits you don’t want, you can just create a new branch with a HEAD at the point you want.

    Now, if you really do want to cherry-pick a range of commits, for whatever reason, an elegant way to do this is to just pull of a patchset and apply it to your new integration branch:

    git format-patch A..B
    git checkout integration
    git am *.patch

    This is essentially what git-rebase is doing anyway, but without the need to play games. You can add --3way to git-am if you need to merge. Make sure there are no other *.patch files already in the directory where you do this, if you follow the instructions verbatim…

    I wrapped VonC’s code into a short bash script, git-multi-cherry-pick, for easy running:

    if [ -z $1 ]; then
        echo "Equivalent to running git-cherry-pick on each of the commits in the range specified.";
        echo "";
        echo "Usage:  $0 start^..end";
        echo "";
        exit 1;
    git rev-list --reverse --topo-order $1 | while read rev 
      git cherry-pick $rev || break 

    I’m currently using this as I rebuild the history of a project that had both 3rd-party code and customizations mixed together in the same svn trunk. I’m now splitting apart core 3rd party code, 3rd party modules, and customizations onto their own git branches for better understanding of customizations going forward. git-cherry-pick is helpful in this situation since I have two trees in the same repository, but without a shared ancestor.

    All the above options will prompt you to resolve merge conflicts. If you are merging changes committed for a team, it is difficult to get resolved the merge conflicts from developers and proceed. However, “git merge” will do the merge in one shot but you can not pass a range of revisions as argument. we have to use “git diff” and “git apply” commands to do the merge range of revs. I have observed that “git apply” will fail if the patch file has diff for too many file, so we have to create a patch per file and then apply. Note that the script will not be able to delete the files that are deleted in source branch. This is a rare case, you can manually delete such files from target branch. The exit status of “git apply” is not zero if it is not able to apply the patch, however if you use -3way option it will fall back to 3 way merge and you don’t have to worry about this failure.

    Below is the script.

    enter code here
        # This script will merge the diff between two git revisions to checked out branch
        # Make sure to cd to git source area and checkout the target branch
        # Make sure that checked out branch is clean run "git reset --hard HEAD"
        echo Start version: $START
        echo End version: $END
        mkdir -p ~/temp
        echo > /tmp/status
        #get files
        git --no-pager  diff  --name-only ${START}..${END} > ~/temp/files
        echo > ~/temp/error.log
        # merge every file
        for file in `cat  ~/temp/files`
          git --no-pager diff --binary ${START}..${END} $file > ~/temp/git-diff
          if [ $? -ne 0 ]
    #      Diff usually fail if the file got deleted 
            echo Skipping the merge: git diff command failed for $file >> ~/temp/error.log
            echo Skipping the merge: git diff command failed for $file
            echo "STATUS: FAILED $file" >>  /tmp/status
            echo "STATUS: FAILED $file"
        # skip the merge for this file and continue the merge for others
            rm -f ~/temp/git-diff
          git apply  --ignore-space-change --ignore-whitespace  --3way --allow-binary-replacement ~/temp/git-diff
          if [ $? -ne 0 ]
    #  apply failed, but it will fall back to 3-way merge, you can ignore this failure
             echo "git apply command filed for $file"
           STATUS=`git status -s $file`
           if [ ! "$STATUS" ]
    #   status is null if the merged diffs are already present in the target file
             echo "STATUS:NOT_MERGED $file"
             echo "STATUS: NOT_MERGED $file$"  >>  /tmp/status
    #     3 way merge is successful
             echo STATUS: $STATUS
             echo "STATUS: $STATUS"  >>  /tmp/status
        echo GIT merge failed for below listed files
        cat ~/temp/error.log
        echo "Git merge status per file is available in /tmp/status"

    Another option might be to merge with strategy ours to the commit before the range and then a ‘normal’ merge with the last commit of that range (or branch when it is the last one). So suppose only 2345 and 3456 commits of master to be merged into feature branch:


    in feature branch:

    git merge -s ours 4567
    git merge 2345

    Assume that you have 2 branches,

    “branchA” : includes commits you want to copy (from “commitA” to “commitB”

    “branchB” : the branch you want the commits to be transferred from “branchA”


     git checkout <branchA>

    2) get the IDs of “commitA” and “commitB”


    git checkout <branchB>


    git cherry-pick <commitA>^..<commitB>

    5) In case you have a conflict, solve it and type

    git cherry-pick --continue

    to continue the cherry-pick process.

    Git Baby is a git and github fan, let's start git clone.