911

If I want to merge into a Git branch the changes made only to some of the files changed in a particular commit which includes changes to multiple files, how can this be achieved?

Suppose the Git commit called stuff has changes to files A, B, C, and D but I want to merge only stuff's changes to files A and B. It sounds like a job for git cherry-pick but cherry-pick only knows how to merge entire commits, not a subset of the files.

1
  • If git gui is available, then I do it like Cascabel. If not, then Tyrone Wilson's way is good for fine granular selection of changes. Commented Nov 17, 2023 at 11:12

15 Answers 15

1023

I'd do it with cherry-pick -n (--no-commit) which lets you inspect (and modify) the result before committing:

git cherry-pick -n <commit>

# unstage modifications you don't want to keep, and remove the
# modifications from the work tree as well.
# this does work recursively!
git checkout HEAD <path>

# commit; the message will have been stored for you by cherry-pick
git commit

If the vast majority of modifications are things you don't want, instead of checking out individual paths (the middle step), you could reset everything back, then add in what you want:

# unstage everything
git reset HEAD

# stage the modifications you do want
git add <path>

# make the work tree match the index
# (do this from the top level of the repo)
git checkout .
16
  • 27
    In addition to git checkout . I would recommend also git clean -f to remove any new but unwanted files introduced by the cherry-picked commit.
    – radeklat
    Commented Jul 5, 2015 at 17:05
  • 7
    Additional note for the latter method: I use git add -p which lets you decide interactively which changes you want to add to the index per file
    – matthaeus
    Commented Oct 13, 2015 at 10:58
  • 8
    This is not so great in the case that the cherry-picked commit doesn't apply to the current working copy because it's so different, but that one file would apply cleanly. Commented Apr 22, 2016 at 0:12
  • 13
    You can also unstage selectively with git reset -p HEAD. It's the equivalent of add -p but very few know that it exists. Commented Mar 14, 2017 at 9:09
  • 4
    This doesn't seem to preserve authorship (at all). In some cases that won't matter, in other cases it will.
    – AlanSE
    Commented Sep 13, 2019 at 17:42
281

The other methods didn't work for me since the commit had a lot of changes and conflicts to a lot of other files. What I came up with was simply

git show SHA -- file1.txt file2.txt | git apply -

It doesn't actually add the files or do a commit for you so you may need to follow it up with

git add file1.txt file2.txt
git commit -c SHA

Or if you want to skip the add you can use the --cached argument to git apply

git show SHA -- file1.txt file2.txt | git apply --cached -

You can also do the same thing for entire directories

git show SHA -- dir1 dir2 | git apply -
16
  • 4
    Interesting method, thanks. But doesn't show SHA -- file | apply basically do the same as checkout SHA -- file as in Mark Longair's answer? Commented Apr 22, 2015 at 10:09
  • 14
    Nope, checkout SHA -- file will checkout exactly the version at SHA, while show SHA -- file | apply will apply only the changes in SHA (just like cherry-pick does). It matters if (a) there are more than one commit changing the given file in the source branch, or (b) there is a commit changing the file in your current target branch. Commented Apr 22, 2015 at 23:59
  • 19
    Just found another great use for this: selective revert, for when you only want to revert one file (since git revert undoes the entire commit). In that case just use git show -R SHA -- file1.txt file2.txt | git apply - Commented Oct 30, 2015 at 2:22
  • 4
    @RoeiBahumi that has quite a different meaning. git diff SHA -- file1.txt file2.txt | git apply - means apply all the differences between the current version of the file and the version at SHA to the current version. In essence it is the same as git checkout SHA -- file1.txt file2.txt. See my earlier comment for why that is different to what the git show version. Commented Dec 14, 2015 at 23:35
  • 13
    In case you have to resolve conflicts, use git apply -3 - instead of just git apply -, then if a conflict occurs, you can use your standard conflict resolution technique, including using git mergetool.
    – qwertzguy
    Commented Apr 4, 2016 at 16:52
183

I usually use the -p flag with a git checkout from the other branch which I find easier and more granular than most other methods I have come across.

In principle:

git checkout <other_branch_name> <files/to/grab in/list/separated/by/spaces> -p

example:

git checkout mybranch config/important.yml app/models/important.rb -p

You then get a dialog asking you which changes you want in "blobs" this pretty much works out to every chunk of continuous code change which you can then signal y (Yes) n (No) etc for each chunk of code.

The -p or patch option works for a variety of commands in git including git stash save -p which allows you to choose what you want to stash from your current work

I sometimes use this technique when I have done a lot of work and would like to separate it out and commit in more topic based commits using git add -p and choosing what I want for each commit :)

7
  • 5
    I regularly use git-add -p, but I didn't know git-checkout also has a -p flag - does that fix the merging problems the non--p answer has? Commented Mar 2, 2016 at 11:45
  • 1
    at least -p would allow for a manual edit for such a conflicting section, which cherry-pick would probably also yield anyway. I'll test this next time I need it, definitely an interesting approach Commented Mar 2, 2016 at 12:54
  • 5
    One of the two best answers that don't kill concurrent changes to the branches. Commented Nov 17, 2016 at 19:20
  • 1
    See this answer for how to select which hunks to apply: stackoverflow.com/a/10605465/4816250 The 's' option in particular was very helpful.
    – jvd10
    Commented Dec 9, 2016 at 16:16
  • 1
    git reset -p HEAD also allows the -p which can be quit handy when you only want to remove some patches from the index. Commented Mar 14, 2017 at 9:33
70

The situation:

You are on your branch, let's say master and you have your commit on any other branch. You have to pick only one file from that particular commit.

The approach:

Step 1: Checkout on the required branch.

git checkout master

Step 2: Make sure you have copied the required commit hash.

git checkout commit_hash path\to\file

Step 3: You now have the changes of the required file on your desired branch. You just need to add and commit them.

git add path\to\file
git commit -m "Your commit message"
4
  • 3
    Awesome! Also worked for all changes in a directory with \path\to\directory\ for me
    – zaggi
    Commented Apr 3, 2020 at 22:16
  • 3
    Overwrites any changes made to the target branch. Commented Jun 10, 2021 at 8:52
  • This works if that commit is exactly the file you need (that's what checkout gets you), but does not work if you have any changes (on master in your example) to that file (which is what using cherry-pick usually solves), as it'll completely replace the file instead of just pick the changes into it.
    – Jimbly
    Commented Apr 21, 2023 at 16:29
  • If you've just committed to the wrong branch, this solution by @techdreams is simpler than using a cherry-pick to pull it into the correct branch, at least for me.
    – Randall
    Commented May 17, 2023 at 17:41
53

Perhaps the advantage of this method over Jefromi's answer is that you don't have to remember which behaviour of git reset is the right one :)

 # Create a branch to throw away, on which we'll do the cherry-pick:
 git checkout -b to-discard

 # Do the cherry-pick:
 git cherry-pick stuff

 # Switch back to the branch you were previously on:
 git checkout -

 # Update the working tree and the index with the versions of A and B
 # from the to-discard branch:
 git checkout to-discard -- A B

 # Commit those changes:
 git commit -m "Cherry-picked changes to A and B from [stuff]"

 # Delete the temporary branch:
 git branch -D to-discard
6
  • 3
    thanks for your answer. Now that inspired me to think, why not skip the cherry-pick and directly use git checkout stuff -- A B? And with git commit -C stuff the commit message would remain the same as well Commented Apr 19, 2011 at 14:21
  • 12
    @Tobias: That would work only if the files modified on stuff have not been modified on your current branch or anywhere between the common ancestor of HEAD and stuff and the tip of stuff. If they have, then cherry-pick creates the correct result (essentially the result of a merge), while your method would throw away the changes in the current branch, and keep all of the changes from the common ancestor up to stuff - not just the ones in that single commit.
    – Cascabel
    Commented Apr 19, 2011 at 14:32
  • 2
    @Tobias Kienzler: I was assuming that your starting point was sufficiently different from the parent of stuff that the result of the cherry pick would leave A and B with different content from their content in the commit stuff. However, if it would just be the same, you're right - you could just do as you say. Commented Apr 19, 2011 at 14:34
  • @Jeromi, @Mark: thanks for your feedback, in my case I'm treating branches with entirely disjunct files which led me to my suggestion. But indeed I'd had run into trouble with it sooner or later, so thank you for bringing this up Commented Apr 19, 2011 at 14:47
  • I think my answer in this other thread may be what you're after.
    – Ian
    Commented Sep 8, 2015 at 14:34
51

Cherry pick is to pick changes from a specific "commit". The simplest solution is to pick all changes of certain files is to use

 git checkout source_branch <paths>...

In example:

$ git branch
* master
  twitter_integration
$ git checkout twitter_integration app/models/avatar.rb db/migrate/20090223104419_create_avatars.rb test/unit/models/avatar_test.rb test/functional/models/avatar_test.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   app/models/avatar.rb
#   new file:   db/migrate/20090223104419_create_avatars.rb
#   new file:   test/functional/models/avatar_test.rb
#   new file:   test/unit/models/avatar_test.rb
#
$ git commit -m "'Merge' avatar code from 'twitter_integration' branch"
[master]: created 4d3e37b: "'Merge' avatar code from 'twitter_integration' branch"
4 files changed, 72 insertions(+), 0 deletions(-)
create mode 100644 app/models/avatar.rb
create mode 100644 db/migrate/20090223104419_create_avatars.rb
create mode 100644 test/functional/models/avatar_test.rb
create mode 100644 test/unit/models/avatar_test.rb

Sources and full explanation http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/

UPDATE:

With this method, git will not MERGE the file, it will just override any other change done on the destination branch. You will need to merge the changes manually:

$ git diff HEAD filename

4
  • 8
    I thought so too, but this fails horribly if the files have changed on both branches since it discards the changes of your current branch Commented Dec 4, 2013 at 13:24
  • You are right, it is a must to clarify that this way git doesn't MERGE, it just override. You can then do "git diff HEAD filename" to see what changed and do the merge manually.
    – cminatti
    Commented Dec 18, 2013 at 14:12
  • This worked well for me. A colleague had made a comment on a pull request, that some changes should be split into a separate request in order to separate the issues clearly. Your method worked well for this case.
    – 4thex
    Commented Feb 2, 2022 at 7:58
  • You can also use it to grab the specific file(s) from a particular commit git checkout e0032947bd37f44044962ae2f7229d339944f83c example.txt Commented Jun 28, 2022 at 8:38
38

For the sake of completness, what works best for me is:

git show YOURHASH --no-color -- file1.txt file2.txt dir3 dir4 | git apply -3 --index -

It does exactly what OP wants. It does conflict resolution when needed, similarly how merge does it. It does git add but not git commit your new changes, so check your git status.

4
  • 6
    that's beautiful Commented Jun 15, 2020 at 16:16
  • Thanks! Can you mention what the 3 is for (... git apply -3 --index ...)? Commented May 3, 2021 at 22:02
  • 4
    -3 signifies to use a "3-way merge fallback". Which in practice means git can insert familiar conflict markers or it can bypass a change that has been already applied. The default git apply behavior is too strict for my taste, it refuses to apply the entire patch on a slightest discrepancy.
    – kubanczyk
    Commented May 4, 2021 at 18:42
  • 1
    you saved me. thanks. Commented Sep 22, 2021 at 11:15
22

Sometimes it could be easier to use checkout to bring specific files from a commit. In my opinion it gives you more control.

I would do it like this:

git checkout <branch|hash> -- path/to/file1 path/to/filen

Then unstage the necessary changes to adapt the code and test it before do commit. If everything works as expected, then commit.

1
  • Identical to multiple existing answers.
    – matt
    Commented Nov 20, 2021 at 20:04
18

I would just cherry-pick everything, then do this:

git reset --soft HEAD^

Then I would revert the changes I don't want, then make a new commit.

1
  • 1
    This is not efficient if the cherry-pick would cause lots of conflicts on files you don't need.
    – thanos.a
    Commented Oct 13, 2022 at 10:13
13

Use git merge --squash branch_name this will get all changes from the other branch and will prepare a commit for you. Now remove all unneeded changes and leave the one you want. And git will not know that there was a merge.

2
  • Thanks, I didn't know about that merge option. It's a viable alternative if you want to cherry-pick most of an entire branch (but in contrast to cherry-pick it won't work if there is no common ancestor) Commented Oct 31, 2017 at 7:32
  • "git will not know that there was a merge"? I thought git knew everything? :\
    – jtlz2
    Commented Jul 19, 2023 at 8:02
7

I found another way which prevents any conflicting merge on cherry-picking which IMO is kind of easy to remember and understand. Since you are actually not cherry-picking a commit, but part of it, you need to split it first and then create a commit which will suit your needs and cherry-pick it.

First create a branch from the commit you want to split and checkout it:

$ git checkout COMMIT-TO-SPLIT-SHA -b temp

Then revert previous commit:

$ git reset HEAD~1

Then add the files/changes you want to cherry-pick:

$ git add FILE

and commit it:

$ git commit -m "pick me"

note the commit hash, let's call it PICK-SHA and go back to your main branch, master for example forcing the checkout:

$ git checkout -f master

and cherry-pick the commit:

$ git cherry-pick PICK-SHA

now you can delete the temp branch:

$ git branch -d temp -f
6

You can use:

git diff <commit>^ <commit> -- <path> | git apply

The notation <commit>^ specifies the (first) parent of <commit>. Hence, this diff command picks the changes made to <path> in the commit <commit>.

Note that this won't commit anything yet (as git cherry-pick does). So if you want that, you'll have to do:

git add <path>
git commit
1
  • this way you can specify any valid range if the resulting doesn't apply, you can opt-in to 3-way merge with -3 or --3way switch: ... | git apply --3way
    – voiger
    Commented Sep 29, 2021 at 15:28
2

Merge a branch into new one (squash) and remove the files not needed:

git checkout master
git checkout -b <branch>
git merge --squash <source-branch-with-many-commits>
git reset HEAD <not-needed-file-1>
git checkout -- <not-needed-file-1>
git reset HEAD <not-needed-file-2>
git checkout -- <not-needed-file-2>
git commit
2

Automating a bit more:

#!/usr/bin/env bash

filter_commit_to_files() {
    FILES="$1"
    SHA="$2"
    git show "$SHA" -- $FILES | git apply --index -
    git commit -c "$SHA"
}

Example usage:

filter_commit_to_files "file1.txt file2.txt" 07271c5e

I define it via copy and paste from here right into my shell. You don't need a here document.

2

Checkout with Patch Flag

An easy way to accomplish what you are describing is through a checkout --patch. Modify the four variables I provided at the top. The script does the following:

  1. Clones the branch that contains your commit ( source branch )
  2. Checkout the branch you wish to move the file to ( target branch )
  3. Checkout the source branch at desired commit revision, supply the patch flag and relative location to the file as a parameter.
  4. Add, commit, push

This has always been the easiest method for me. Step #3 does create an interactive shell though, but you can default option the entire thing if you want to clobber the destination.

source_branch=branch_with_file_you_want
destination_branch=file_go_here
rev=757c47d4
relative_file_path=structures/serializers/node.py
message="Patching a file from $source_branch to $destination_branch"

git clone https://github.com/yourepo/app.git -b $source_branch $source_branch
cd $source_branch
git checkout $destination_branch
git checkout $rev --patch $source_branch $relative_file_path
git add $relative_file_path
git commit -m "$message"
git push

If you're remote is GitLab you can use git push -o merge_request.create if you need an MR

Not the answer you're looking for? Browse other questions tagged or ask your own question.