我正在与一些其他开发人员合作开发一个相对较小但快速变化的项目(Web应用程序)。我们使用Git进行源代码控制。
我们开始创建 stable 分支,这是部署到实时生产Web服务器的分支。 主分支是部署到辅助“不稳定”服务器以进行测试的部分。每当我们觉得 master 分支准备好上线时,我们就将它合并到 stable 。
但是,我们想要一个后来的主提交,但不是之前的一些提交,所以我们使用cherry-pick
将该更改拉入< EM>稳定。这会创建一个与 master 中的更改相同的新提交,并且感觉好像我们正在丢失Git否则提供的好历史。
是否有更好的方法来处理这种不稳定/稳定的部署模型?
我想到的一个解决方案是使用功能分支,并且只有在我们希望它上线后才将功能分支合并到 master 中。然后我们tag
每个部署而不是稳定的分支。
答案 0 :(得分:3)
阅读http://nvie.com/git-model并使用hxxp://github.com/nvie/gitflow
答案 1 :(得分:2)
你说这是正确的,这会破坏历史git保持挑选。这里要考虑的是,为什么你不希望前面的提交稳定?
(nb。如果它的一些后续提交你尚未准备好移植,你当然可以使用git merge <commit-id>
而不是挑选来保持历史干净 - 未来的合并也很聪明,不会重复提交/变更)
如果您不想要它们,因为它们还没有为主线做好准备,或者经过全面测试,那么是什么让您确信所需的提交(取决于它们及其状态)是否准备就绪?
如果因为它们还没有为稳定做好准备,并且你想要的提交不依赖于它们,那么你就不会像你一样有效地进行分支:那个提交可能是在一个单独的主题分支上(它只包含你感兴趣的功能所需的提交),然后一旦你确定它的稳定性,只需合并那个分支。然后,您可以将需要此功能的其他分支重新绑定到stable,或者只是将功能分支合并到它们中(再一次,git在这里非常聪明,关于未来的合并)。
在您工作时考虑提交的影响需要更多的纪律(因为您已经提前或经常提交;)但是它使分支/合并工作流程更加简单 - git checkout -b new-feature
是你的朋友在主题分支中工作时快速添加其他无关更改的提交(或git checkout -b new-feature master
,如果你特别严格,并且工作树周围没有额外的更改)
答案 2 :(得分:0)
在git中,只需为您想要执行的每种类型的更改创建一个新分支。然后,当完成更改时,您可以先将其与不稳定分支合并(最终合并到稳定分支)。
如果只想将某些更改合并到稳定分支中,可以通过选择正确的分支来选择所需的功能。
答案 3 :(得分:0)
我们使用以下工作流程:
如果这个圈子运行得足够快,几乎没有冲突。所有分支都相对较短。每个人都靠近主人。
为了转移到prod,我们在部署验证后手动在UAT存储库中创建一个分支。