问题描述
仅供参考：我最近已经从颠覆过渡，所以我所要引用的只是我在那所做的事情。
我们有一些团队成员经常向存储库提交错误代码。我没有办法防止这种情况，我也没有寻找办法。但是我过去在Subversion中所做的就是在更新本地副本时，可以轻松地在同步视图中看到 所有 仓库更改。而且我可以在那里进行代码审查，逐行合并它们的更改，然后对我的本地副本进行更改，从本质上迫使冲突+合并来纠正他们的错误代码。只需一个视图即可完成所有操作，而不必担心我面前的两个版本-本地与远程，并立即查看所有文件。
我不知道如何在eGit中做到这一点。同步视图仅显示我对存储库的提交，而不显示传入的更新。而且，执行拉动操作并不能让我交互式地修改传入的 non-conflicting 文件，这非常重要，因为它们的大多数更新都不会合并冲突。因此，现在我必须提取更新，然后找出它们一次修改了哪些文件，然后从那里开始。
如何完成与SVN中相同的更新/合并流程？
解决方法
此解决方案不使用Eclipse，但也不应干扰Eclipse。也许这些命令可以通过Eclipse UI以某种方式完成，但我不知道它的局限性。
使用git和cd打开终端，进入项目目录。
首先运行git fetch以下载队友所做的所有更改。请注意，这是一个相当“安全”的命令-它不会触及您的工作目录，也不会导致任何冲突。它只是“更新”您从中获取的远程存储库的内部本地副本，因此它知道自上次获取以来所做的所有更改。 （git pull只是fetch，后跟merge自动）。
获取后，您可以在commit graph中查看所有新（旧）提交及其各自的更改。
如果要让某些提交的某些更改应用于工作目录，请记下该提交的哈希值，然后运行git checkout -p <hash>。
这将启动一个交互式提示，使您可以从提交中选择要应用于工作目录的更改，以及不希望应用于工作目录的更改。
如果更改的粒度不够细，则可以使用s将当前块进一步分成较小的块。
我知道您并没有要求这样做，但是万一有人遇到这个问题，这是一种极为尴尬的工作方式，而且很少见。通常，您的队友应该在单独的功能分支中编写不需要的更改，这些分支仅在准备就绪时才合并到主分支中。每个人都来自主分支，它应该是金色的，只有积极的变化。必须不断地挑选其他人所做的所有更改听起来很乏味，而且只有当更多的人添加到存储库中时，情况才会变得更糟。如果您正在寻找一种更简单的工作方式，请参见GitHub flow。
,在Git中，工作方式与SVN中的完全不同。
在SVN中，您首先将服务器的最新状态合并到本地/工作副本中。在合并中，您通过还原或改进其他更改来充当网守。之后，将您的版本提交到服务器，该服务器将其作为新修订版本放在历史记录堆栈的顶部。
相反，在Git中，您想到的是变化，而不是状态。提交是可以应用于多个分支（cherry picking）的更改。即使要更改的文件不同也可以。在SVN中，当同一文件受到影响时，已经存在合并冲突，但是在Git中，只有当同一行或附近的行受到影响时，您才会发生冲突。这意味着与SVN相比，在Git中您几乎不需要手动解决冲突。好处是，这还意味着可以在以后的某个时间点还原更改。
在Git中，将rebase（或merge）任务和网守任务作为两个单独的任务进行。首先执行 Pull ，这样，当同时有其他更改被推送到远程服务器时，您的更改将被移至历史记录的末尾。仅在极少数情况下（当您的更改/提交影响同时被其他人更改的行时），您才需要在 Git Staging 视图中手动解决这些冲突。但是在大多数情况下，您只需执行 Pull ，即可准备提交更改并在 Git Staging 视图中进行更改。与所做的更改无关，您可以在“历史记录” 视图中查看其他人所做的更改，并在以后还原或改进它们。要还原提交，请右键单击并选择 Revert Commit ，以创建具有反向更改的新提交。如果要编辑此还原提交（用于部分还原），请右键单击上一个提交并选择 Reset> Soft或Mixed 。