一位同事和我现在都在主分公司工作。我在工作树中有一些我不想提交的代码（调试语句等）。现在，如果他对某些相同的文件进行更改，我就无法合并它们：
$ git merge origin/master
Updating 1b8c5c6..eb44c23
error: Entry 'blah.java' not uptodate. Cannot merge.
来自subversion背景，我习惯于在从存储库中提取更改时自动合并工作树，如果存在冲突，我会手动解决它们。
我发现在git中这样做的最快方法是：
$ git stash
$ git merge origin/master
$ git stash pop
本质上，删除我未提交的更改，执行合并然后重新应用更改。如何告诉merge自动将我的工作树与我想要引入的更改合并？
据我所知，你能做的最好的就是你已经拥有的git stash。我也觉得奇怪，合并只想处理干净的树木。
忘掉你从颠覆中学到的一切。
在引入外部更改之前始终提交。
想象一下，你有一棵大多数工作的树 - 也许并不完美，但你正在取得一些进展。然后你去做一个合并，你带来的代码只会造成严重破坏（本身就是错误，需要处理的冲突太多等等）。如果你可以撤消它，那不是很好吗？
如果你承诺，你可以。如果你不这样做，你就会受苦。
记住：你所提交的内容并不一定是你所推动的内容，但是你没有承诺的东西很容易丢失。
只做安全和轻松的事情，尽早提交并经常提交。
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 dropgit pull将“正常工作”
然而：由于历史更清晰，git pull --rebase将“工作得更好”
没有合并提交;您的更改将在上游更改后提交
除此以外：
git pull将需要手动解决冲突：
git pull
解决合并冲突
git add FILE为每个冲突的文件
git commit
由于历史更加清晰，git pull --rebase仍然可以“更好地工作”
但是，解决合并冲突可能要困难得多有关详细说明，请参阅：https://happygitwithr.com/pull-tricky.html
您无法告诉git merge合并对本地存储库进行更改的文件的更改。这可以防止您在合并失败时丢失更改。
使用CVS和SVN合并方法，如果您在更新之前没有手动复制文件并且在合并时将它们加扰，则必须手动重新编辑才能恢复到良好状态。
如果您在进行合并之前提交更改或存储它们，则一切都是可逆的。如果合并不顺利，你可以尝试几种方法使其成功，并选择效果最好的方法。
如果您确实提交了实验或调试更改，您可以使用git rebase在通过git merge提交之后移动它们，以便更容易摆脱它们或避免意外地将它们推送到存储库。
请注意，在已推送到共享存储库的分支上使用git rebase会让每个从该存储库中提取的人感到悲伤。
在这些情况下，我更喜欢使用git stash，但如果合并更改了我已编辑但未提交的文件，我只会使用它。