如何让 git merge 处理对我的工作树的未提交更改？

How to make git merge handle uncommitted changes to my working tree?

提问by Jeremy Huiskamp

A co-worker and I are both working on the master branch at the moment. I have some code in my working tree that I don't want to commit (debugging statements and the like). Now if he commits changes to some of those same files, I can't merge them:

我和一个同事目前都在主分支上工作。我的工作树中有一些我不想提交的代码（调试语句等）。现在，如果他对某些相同的文件进行更改，我将无法合并它们：

$ git merge origin/master
Updating 1b8c5c6..eb44c23
error: Entry 'blah.java' not uptodate. Cannot merge.

Coming from a subversion background, I'm used to having my working tree automatically merged when I pull changes from the repository and if there are conflicts, I resolve them manually.

来自颠覆背景，我习惯于在从存储库中提取更改时自动合并我的工作树，如果存在冲突，我会手动解决它们。

The quickest way I have found to do this in git is:

我发现在 git 中执行此操作的最快方法是：

$ git stash
$ git merge origin/master
$ git stash pop

Essentially, removing my uncommitted changes, doing the merge and then re-applying the changes. How can I tell merge to automatically merge my working tree with the changes I'm trying to pull in?

本质上，删除我未提交的更改，进行合并，然后重新应用更改。我如何告诉合并自动将我的工作树与我试图引入的更改合并？

采纳答案by Norman Ramsey

As far as I can tell, the best you can do is what you already have with git stash. I too find it strange that merge wants to deal only with clean trees.

据我所知，你能做的最好的事情就是你已经拥有的git stash. 我也觉得奇怪的是 merge 只想处理干净的树。

回答by Dustin

Forget everything you ever learned from subversion.

忘记你从颠覆中学到的一切。

Always commit before introducing external changes.

在引入外部更改之前始终提交。

Imagine you had a mostly-working tree -- maybe not perfect, but you're making some progress. Then you go to do a merge and the code you're bringing in just wreaked havoc (was buggy itself, too many conflicts to deal with, etc...). Wouldn't it be nice if you could just undo that?

想象一下，你有一个主要工作的树——也许并不完美，但你正在取得一些进展。然后你去做一个合并，你带来的代码只是造成了严重破坏（本身就有问题，需要处理的冲突太多，等等......）。如果你能撤消那不是很好吗？

If you commit, you can. If you don't, you're just going to suffer.

如果你承诺，你可以。如果你不这样做，你只会受苦。

Remember: What you commit doesn't haveto be what you push, but what you don't commit you can easily lose.

记住：你犯了什么不有是你推什么，但你不承诺，你可以很容易失去。

Just do the safe and easy thing and commit early and commit often.

只要做安全和容易的事情，尽早提交并经常提交。

回答by Leonardo Gonzalez

• If local work is uncommitted
  • And you've introduced completely new files that don't exist in the remote branch:
  • Or the files affected by your local work have ZERO overlap with the files affected by the changes you need to pull from the remote:
    • You're in luck: git pullwill "just work"
  • Otherwise:
    • If your local changes have NO overlap with changes you are pulling:
      • git stash will work:
        • git stash save
        • git pull
        • git stash pop
    • If your local changes have SOME overlap with changes you are pulling:
      • git stash will require manual conflict resolution:
        • git stash save
        • git pull
        • git stash pop
        • resolve merge conflicts
        • git reset
        • git stash drop
• If local work is committed
  • And the files affected by your local work have ZERO overlap with the files affected by
    • You're in luck: git pullwill "just work"
    • However: git pull --rebasewill "work even better" because of a cleaner history
    • there is no merge commit; your changes will be committed after upstream changes
  • Otherwise:
    • git pull will require manual conflict resolution:
      • git pull
      • resolve merge conflicts
      • git add FILEfor each conflicting FILE
      • git commit
    • git pull --rebasecould still "work even better" because of a cleaner history
      • however, resolving merge conflicts could be much harder

• 如果本地工作未提交
  • 并且您引入了远程分支中不存在的全新文件：
  • 或者受您本地工作影响的文件与受您需要从远程拉取的更改影响的文件零重叠：
    • 你很幸运：git pull会“正常工作”
  • 除此以外：
    • 如果您的本地更改与您正在拉取的更改没有重叠：
      • git stash 将起作用：
        • git stash save
        • git pull
        • git stash pop
    • 如果您的本地更改与您正在提取的更改有一些重叠：
      • git stash 需要手动解决冲突：
        • git stash save
        • git pull
        • git stash pop
        • 解决合并冲突
        • git reset
        • git stash drop
• 如果本地工作已提交
  • 并且受您本地工作影响的文件与受您本地工作影响的文件零重叠
    • 你很幸运：git pull会“正常工作”
    • 然而：git pull --rebase由于更清晰的历史，将“工作得更好”
    • 没有合并提交；您的更改将在上游更改后提交
  • 除此以外：
    • git pull 需要手动解决冲突：
      • git pull
      • 解决合并冲突
      • git add FILE对于每个冲突的文件
      • git commit
    • git pull --rebase由于更清晰的历史，仍然可以“更好地工作”
      • 然而，解决合并冲突可能要困难得多

For a detailed explanation, please see: https://happygitwithr.com/pull-tricky.html

详细解释请看：https: //happygitwithr.com/pull-tricky.html

回答by Jamey Hicks

You cannot tell git mergeto merge changes on files that have changes with respect to your local repository. This protects you from losing your changes on those times when a merge goes badly.

您不能告诉git merge合并对本地存储库有更改的文件的更改。这可以保护您在合并失败时不会丢失更改。

With the CVS and SVN approach to merging, if you did not manually copy your files before the update and it scrambled them on merge, you have to manually re-edit to get back to a good state.

使用 CVS 和 SVN 合并方法，如果您在更新之前没有手动复制文件并且在合并时对它们进行了加扰，则您必须手动重新编辑以恢复到良好状态。

If you either commit your changes or stash them before doing a merge, everything is reversible. If the merge does not go well you can try several ways of making it work out and go with the one that works best.

如果您在进行合并之前提交更改或隐藏它们，则一切都是可逆的。如果合并不顺利，您可以尝试多种方法来解决问题，并选择最有效的方法。

If you do commit experimental or debug changes, you might use git rebaseto move them after the commits you get via git mergeto make it easier to get rid of them or to avoid pushing them to a repository accidentally.

如果您确实提交了实验性或调试性更改，您可能会git rebase在通过提交后移动它们git merge，以便更轻松地摆脱它们或避免将它们意外推送到存储库。

Note that using git rebaseon a branch you have pushed to a shared repository will cause grief for everyone who is pulling from that repository.

请注意，git rebase在已推送到共享存储库的分支上使用会导致从该存储库中提取的每个人的悲伤。

I prefer to use git stashin these cases, but I only use it if the merge changes files that I have edited and not committed.

我更喜欢git stash在这些情况下使用它，但我只在合并更改我已编辑但未提交的文件时使用它。