我们正在使用GitFlow进行相当标准的设置：
我们确实在开发和master之间存在一些差异，因为我们希望master指向某些版本的NuGet依赖项，例如在开发指向其他版本的依赖项时。
我们发现当我们执行GitFlow Hotfix并完成该修补程序时，在它从修补程序分支合并到develop时，它会尝试将这些配置差异从master合并到develop中，即使这些配置更改不是作为修补程序的一部分完成的。
我的同事断言，这个打嗝可能是主分支的副作用，当我们最初使用GitFlow Releases功能时，我们最初转移到GitFlow而不是使用我们的分支。
是否有人对此类设置或症状有任何经验或有任何尝试尝试解决此问题的建议？我们正在考虑尝试使用GitFlow Release功能重新创建master，或者使用Git属性忽略要合并的文件，但感觉可能有更好的解决方法。
答案 0 :(得分：3)
这是因为自master和master之间的“合并基础”以来develop上的配置已在某处更改。 （粗略地说，“合并基础”是master和develop历史上最近的提交。）我想这意味着你的同事走在正确的轨道上。使用特定的GitFlow工具并不严格，但develop应该从master分支（而不是相反），并且（或许更重要的）不应该直接应用更改到master。
如果这些陈述对您来说似乎不合理，那么您所拥有的并不是GitFlow的“相当标准的设置”。
在GitFlow设置中，依赖版本与任何代码更改都没有区别。通常只会发生一些事情：
最常见的事情应该是，功能需要依赖项（或依赖项的新版本），以便更改进入功能分支上的构建配置。从那里它最终合并到develop，然后在发布分支上进行合并到master。
另一种可能性是修补程序中的版本号已更改，因为您需要安全修补程序或依赖项上的某些内容。当然，这应该合并到master和develop。
最后，您可以更改发布分支上的依赖项;但同样，这些更改将合并到master和develop。
共同的主题是，这些应该通常都朝向共同的配置。这不是错误的;如果你声称希望版本在prod中保持不同，那么你就是说你不希望你的开发人员能够进行准确有效的测试。
如果你关注gitflow，那么develop与master有不同版本的依赖关系的唯一原因是该更改尚未流向master;在这种情况下，修补程序合并不会认为master版本应该覆盖develop版本，因为合并基础将在master版本上。
当然，是配置元素，在生产和开发环境（例如连接字符串）之间应该是持久不同的。我的建议是在构建过程中解决这个问题，而不是源控制工作流程。
答案 1 :(得分：-1)
不久之后，gitflow会隐式将整个master合并到develop，当您像这样合并时，会出现master的某些更改远离{{1}的问题}。 （至于你的“我的同事断言......”我并没有完全理解它，但是如何开始分支是无关紧要的。如果它们最初不相关合并仍然会使它们相同，另一个答案解释它）< / p>
我唯一可以建议的是在合并后在develop中恢复该配置。下次develop发生变化时，会触发合并冲突，您可以按照预期的方式手动解决。