对于这个问题含糊其辞，我深表歉意，但我不确定还有什么要问的。
我们有一个使用git作为底层源代码管理的TFS服务器。我们有一个开发分支，人们可以将代码检入到当前的迭代中。然后，当我们要发布时，我们从develop分支出来。从那时起，当人们签入release分支时，他们正在选择将其转移到development分支……有时还是如此。
问题是，当我从发行版进行最终合并以进行开发时，它仍然显示出所有已经挑剔的更改，因为显然TFS太笨了，无法实际查看git分支的差异。相反，它只是显示基于每个工作项的更改历史记录。即使git中的分支是相同的，因为每个更改都已经被精心挑选，但仍将它们显示为TFS中的新更改。
这意味着对于每个发行版，我都必须在本地进行git merge来查看是否存在任何差异（总是因为有人总是忘记挑选某些东西）。然后，在TFS中进行拉取请求之前，我必须仔细检查它们并确认它们还可以，这是一个巨大的痛苦。此外，我还必须关闭强制合并分支机构政策。否则它将所有内容捆绑在一起，并且更改历史记录仍不会合并。如果同时存在多个发行分支，情况将变得更加复杂。
TFS是否会发现一个更好的过程，使TFS能够识别出樱桃签中的更改与原始签入中的更改基本相同，并以此方式更新历史记录？
或者完全不同的东西。我愿意接受建议。
答案 0 :(得分：1)
当您选择一个提交时，它的新版本会收到一个新的提交ID。稍后，当您合并时，git会看到两个不同的提交ID，因此假定它们是两组不同的更改。由于无法确定要应用的更改集，因此您会遇到需要手动解决的冲突-即使这是完全相同的更改集。为了提高速度，git并未进行实际的文件比较-它使用提交ID来确定是否已应用更改。
简而言之，避免这种情况的方法不是选择樱桃而是合并-然后在两个分支中使用相同的提交ID，并且git识别出已应用更改。
我个人非常喜欢GitFlow所描述的过程，但是根据您对过程的描述，我认为，您只需要从选择原始版本到从发行版本合并到->发展。
因此，您的团队会：
release git merge开发由于分支之间的提交ID相同，因此每个合并操作将仅应用尚未应用于develop的更改。因此，即使已经在develop中对某些内容进行了修改，也只有在最近在release中对其进行了修改的情况下，才会引起冲突。
由于您提到在同步发行版本以进行开发时，人们不太愿意（可能）合并其他人的提交，因此以下过程可以避免该问题：
release就像master和develop-IE不允许直接提交release创建一个“功能”分支release develop 现在，release和develop将具有相同的更改，并且每个开发人员仅应对自己的冲突负责。
注意：这会导致许多其他的合并提交，并且当您将release合并到develop中时，这些提交会显示出来。但是，由于来自release的合并提交应该是空的更改，因此我希望几乎不存在冲突。此外，git的历史将变得非常混乱。就我个人而言，我认为这个问题以及为避免该问题而需要使用的重新编制过程具有自己的学习曲线。