问题
I am in branch B. After a bunch of commits, a few files are ready/needed by branch A, but many aren't ready/needed. I want to merge just those files, keeping proper git history. Later, when I really merge, I don't want any misleading trail about the origin of these changes -- they should properly reference the commits they came from, even though changes in other files that were part of those commits were not merged (yet). I guess that means dividing commits into pieces that do vs. don't concern these files.
All proposed solutions for this wind up losing the history of these changes and cause a big problem when I later want to merge B into A but some of B's changes are already there. I want a solution that avoids this.
In tortoise, I can look at the log for a single file and choose some older revision to revert to. So, in principle, I could make a new branch C, from B, and revert all the files I don't want to merge back to the point when B branched from A. Then I could merge C to A. That seems to properly track git history and lets me merge B into A without being surprised that some B changes are already there.
But it's painful to manually identify and revert 20 files, when I just want to merge 2. Why isn't this a common one-step operation? How does tortoise's revert work -- since it can operate on a single file, it must be sub-commit, which is the essential feature I'm looking for. Is it throwing away the fact that I am going from a newer revision to an older one, and making it look like I just made some manual changes that will then conflict with the eventual merge of B back to A?
回答1:
You are looking for cherry pick, a method to pick only certain commits from a branch to be merged.
To merge only certain files (when you don't want to merge a whole commit), you have multiple solutions indeed, i like to use the one well-expressed in this article, it's a pain in the arse anyway, bit it's the simpler i found to to that kind of things.
You can also split some commits and merge only the ones that contains the right files, and you can do like that other article says
回答2:
It's not a common one-step operation because Git is a content tracker, not a file tracker.
You can easily apply changes to specific files from branch B to branch A, just like Tortoise:
# raw file, no history
git checkout A
git checkout B myfile
or
# copy a set of history from someplace else
git checkout A
git cherry-pick commit-hash-1..commit-hash-2
but neither of those will preserve the history as merges from branch B. If that's what you're trying to do, depending on how the commits in branch B are organized, this might be better for you: Git: piecewise merge approach for major version changes?
来源：https://stackoverflow.com/questions/10931034/merge-some-files-now-and-some-later