我有一个由 git 存储库管理的项目。我们使用 progit 分支策略(如已接受的答案中所述，此处:Git branch strategy for small dev team)，其中一个分支是生产分支，另一个分支是开发/测试分支。我们使用 fabric 部署代码。
当我们准备好使用 git 发布新的生产版本时，我们将开发/测试分支 merge 到生产分支中，然后使用 fabric 部署生产分支。问题是开发和生产之间存在代码差异——一些 Logo 发生变化，一些不同的数据库主机/凭证，诸如此类。我一直在保留一个包含差异的 .patch 文件，并让 fabric 在部署生产环境时应用补丁，但这效果不佳。特别是，如果补丁周围的某些代码发生更改，它就会完全失败——补丁无法应用并且我的部署中止。
我一直在想，我是否应该直接将所有更改应用到生产分支？这有什么缺点？
我关心的一个特殊用例是我们是否需要进行修补程序。我们目前通过从生产环境分支，进行更改，然后将该分支 merge 回开发和生产环境来实现这一点。如果生产分支与开发分支不同，当修补程序 merge 到开发分支时，这些更改是否可以 pull 入开发分支？
最佳答案
您的问题基本上可以归结为“我如何在一个分支中进行更改，然后当我 merge 到另一个分支时该更改不会传播？”。这相当简单。在这一点上，我假设您的生产分支基本上只是一系列 merge ，或者来自 dev 分支，或者来自 hotfix 分支。所以大概从你的开发分支做一个 git merge production 不会做任何改变。鉴于此，继续对生产分支进行更改。现在提交它们。现在 checkout 开发分支并运行 git merge -s ours production。这基本上意味着“从生产中 merge ，但拒绝所有他们的更改”。这将创建 merge 提交，但实际上不会触及您的开发分支。
完成 merge 后，您现在可以放心地将生产分支 merge 到开发分支(或者更确切地说， merge 修补程序分支)，因为您的仅生产提交现在已经“merge ”到开发分支中(尽管代码更改本身被拒绝)。因此， merge 您的修补程序分支不会引入仅用于生产的代码。
完成此操作后，您唯一需要返回并重新应用此技巧的时间是您进行更多仅用于生产的更改。如果您在开发分支上所做的更改与仅用于生产的更改发生冲突，则在将开发 merge 到生产中时，您可以继续并毫无问题地接受冲突的生产方面。
关于git - git 中开发分支和生产分支之间的差异存储在哪里？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8996610/