git - 在使用 git 的 TFS 服务器中，如何有效地跨分支合并更改？

Question

如果这个问题有点含糊，我深表歉意，但我不知道该怎么问。

我们有一个使用 git 作为底层源代码控制的 TFS 服务器。我们有一个开发分支，人们将代码检查到当前迭代中。然后，当我们即将发布时，我们从开发分支中分离出来。从那时起，当人们签入发布分支时，他们会挑选它到开发分支......有时无论如何。

问题是，当我从发布到开发进行最终合并时，它仍然显示所有已经被精心挑选的更改，因为显然 TFS 太笨了，无法真正查看 git 分支的差异。相反，它只是显示基于每个工作项的更改历史记录。即使 git 中的分支是相同的，因为每个更改都已经被精心挑选，它仍然将它们显示为 TFS 中的新更改。

这意味着对于每个版本，我都必须在本地进行 git merge 以查看是否有任何差异（总是有差异，因为有人总是忘记挑选一些东西）。然后我必须在 TFS 中执行拉取请求之前检查它们并验证它们是否正常，这是一个巨大的痛苦。此外，我还必须关闭强制合并分支策略。否则，它将所有内容捆绑在一起，并且更改历史记录仍然不会合并。如果同时有多个发布分支，它会变得更加复杂。

有没有更好的流程让 TFS 能够识别出从樱桃挑选出来的更改与原始签入的更改基本相同并以这种方式更新历史记录？

或者完全不同的东西。我愿意接受建议。

标签： gittfs

Answer 1

当你挑选一个提交时，它的新版本会收到一个新的提交 ID。稍后当您合并时，git 会看到两个不同的提交 ID，因此假定它们是两组不同的更改。由于它无法决定应用哪一组更改，因此您会遇到需要手动解决的冲突——即使它是完全相同的一组更改。出于速度效率的原因，git 没有进行实际的文件比较 - 它使用提交 ID 来确定是否已应用更改。

简而言之，避免这种情况的方法不是挑选而是合并——然后在两个分支中都使用相同的提交 ID，并且 git 会识别出应用了更改。

---

就个人而言，我真的很喜欢GitFlow描述的过程，但从你提到的过程来看，我认为你只需要从挑选樱桃切换到从发布 - > 开发合并。

因此，您的团队将：

1. 做出承诺release
2. 将更改移回以开发git merge
3. 重复

由于分支之间的提交 ID 相同，因此每个合并操作只会应用尚未应用到的更改develop。因此，即使某些内容已在 中进行了修改develop，如果它最近也在 中进行了修改，您只会遇到冲突release。

---

由于您提到人们在将发布同步到开发时不习惯（可能）合并其他人的提交，因此以下过程将避免该问题：

1. release像对待master和develop- IE 不允许直接提交
2. 当开发人员需要开始工作时，从release
3. 开发完成后（并审查，如果适用），将“功能”的更改合并到release
4. 然后从“功能”进行第二次合并develop

现在，release并且develop将有相同的更改，每个开发人员将只对自己的冲突负责。

注意：这会导致许多额外的合并提交，当您合并release到develop. 但是，由于来自的合并提交release应该是空更改，我希望冲突几乎不存在。此外，git历史会变得非常纠结。就个人而言，我不认为这是一个问题，并且你需要使用 rebase 过程来避免它有它自己的学习曲线。