我最近从TFS转到了Git，非常喜欢它。
我的工作团队使用git-flow。对于每个功能，我们创建一个功能分支。但是，似乎偶尔会发生的一件事是，当将功能分支推送并向master中创建拉取请求时，将发生合并冲突。为了解决该合并冲突，我将master分支与远程同步，并将master与我的功能分支进行同步，并解决了该合并冲突。
但是现在在我的外发提交中，我不仅将具有“合并冲突修复”，而且还将在该拉取请求中同时进行的master中具有所有其他提交。
因为如果我将本地分支与本地master合并并从master进行推送，我将绕过pull请求（即使这在技术上是可行的），但似乎不正确。我错了吗？
这个问题不仅发生在合并冲突期间，我想这仅仅是关于使功能分支与master保持同步。其他人如何解决呢？我听说过要重新定基，但似乎在我的团队中很少使用。
答案 0 :(得分：0)
Phlippe's comment是正确的：这是正常的，因为您看到的（在Visual Studio中，我假设是？）是功能分支上尚未提交到远程的任何提交。
您的提交历史可能看起来像这样：
A--B--C--D--E [master, origin/master]
\ \
X--Y--Z-----M [feature/mine]
\
[origin/feature/mine]
您在功能分支上所做的工作是X到Z的提交，而在master上的B到E的提交是别人的工作。
当您提到“外发提交”时，可能是将本地分支feature/mine与远程origin/feature/mine进行了比较。后者“包含”提交A及其之前的所有内容以及更改X，Y和Z。您当前位于提交M的本地分支也包含B到E，因为您已将这些更改合并到功能分支中，所以这就是为什么您看到在那里列出那些提交的原因。
这不是问题，因为Git仍然跟踪通过E创建提交B的人，因此您并没有神奇地声明对其或任何内容的所有权。另外，由于这些提交已经包含在origin/master中，因此它们已经在服务器上，因此您不必再次推送它们。
我同样鼓励您考虑重新定级而不是合并。如果您在提交Z的feature/mine上，则可以执行以下操作：
git rebase master
解决所有冲突并完成变基之后，您的历史记录可能如下所示：
A--B--C--D--E [master, origin/master]
\ \
\ X'--Y'--Z' [feature/mine]
\
X--Y--Z [origin/feature/mine]
然后做：
git push --force-with-lease
更新远程功能分支。
这样做的好处是无需额外的合并提交即可保持更干净的历史记录，但这不是必需的。假设您对所有冲突都采用相同的解决方案，那么提交M处的代码将与提交Z'中的代码相同。
请注意，在这种情况下，功能分支仍然包含提交B到E，它们只是直接从master继承而来，而不是通过合并提交而来。没关系，这是希望的：解决合并冲突的唯一方法是将更改放入分支，可以在其中处理冲突。