如何管理反映测试环境的Git分支

Question

我正在组织中工作的站点有三个分支：一个用于测试，分段和生产。代码部署到各自分支机构的现场网站。

这变得有问题（我认为），而且我不确定这是因为我对Git还是一个相当新的东西，或者是一个破碎的过程。

如果另一个开发人员在测试环境中工作，并且我需要快速推出某些东西，那么如何对测试进行更改并将其合并到舞台上，然后在不包括他的所有更改的情况下执行测试？我已经使用git cherry-pick，但我不确定这是否是最佳路线。

感谢您的帮助

Answer 1

那么，对于一个你能避免“上做测试的变化”。

我假设所有分支产生的master。创建一个分支urgent-hotfix，合并到测试中并查看它是否可行（可能包括其他人的更改），然后直接将其合并到分段和产品。

事实上，这三个挂钩部署并不意味着你不能有更多的分支，尤其是修补程序。我的经验法则是“每个开发者一个分支”，它的工作方式非常好。请注意，这并不意味着创建名为devs的分支;它只是意味着两个开发人员不会在同一个分支上工作。

例如，如果我是唯一一个制作功能A的人，我会让feature-A分支并直接提交给它。如果有更多的人在feature-A上工作，我会先创建该分支，然后再分支分支，称为feature-A-part-A，提交到该工作代码并合并工作代码到feature-A。我很确定你可以将它适应你的情况。

Answer 2

您的解决方案最初工作正常，但不能很好地扩展。

更好的方法是将部署与源代码管理分开。为了达到这个目标，你需要大致遵循这些步骤一个释放的过程：

• 创建尚未特定的环境中定义明确的发布包。
• 定义环境以及每个环境所需的配置。
• 在部署到特定环境之前，应用相应的配置。这将版本变成部署。
• 将部署上传到相关环境。

该方法支持尽可能多的环境，只要你想。它还使您能够引入诸如“部署到实时系统之前的规则，我们必须部署到质量检查”等规则。

既然您的发布过程独立于开发过程，那么您可以在Git中使用标准主题分支来处理您描述的情况 - 每个功能都是在不同的主题分支上开发的。所以其他开发人员可以将他的主题分支部署到测试环境中，并且完全不受此影响。