Git在测试环境上分支

Question

我开始在一家刚使用git的公司工作。 我需要一个很好的建议。 首先，我想谈一谈当前的工作流程。

团队的工作流程与常规git基本有很大不同。 分支机构是

Local (feature/hotfix branch from Dev) -> Dev -> Test -> Prod

环境

Dev -> Test -> Prod

1. 每个分支都有不同的配置文件（尚无解决方案。但是我将首先解决此问题），因此，我们无法合并分支。
2. 开发人员正在使用Local（功能/修补程序分支），并将其推入合并到Dev分支中，并在Dev环境中发布其版本（只是补丁版本不断增加（1.0.xxx），我知道这样做不是一件好事。）
3. 然后他们将所做的更改挑选到Test分支中。 并且，他们在测试环境上发布了新版本。 UAT在这里令人陶醉。
4. 当开发人员想要将他们的更改发布到生产环境中时，他们还会选择更改。 并在产品环境中发布新版本。

这里的第一个问题是，由于配置文件的原因，我们无法合并分支，因此我们无法很好地观察分支的历史。

第二个问题是，某些更改应在测试环境1-2上停留两周，更改可能具有长寿命或短寿命。

第三个问题，我们不能使用git特性，例如合并和拉取请求。 我们想使用PR进行代码审查等等。 这对我们很重要。

我可以说在这种情况下，部署过程和版本控制系统是混合的。 因此，我们想使用git-flow之类的东西。 虽然， 我们希望保留这三个环境（开发，测试和生产），并且主要目标是合并分支并使用拉取请求

假设，我们只有开发和掌握分支机构。 开发人员在功能分支上工作。 并将其功能合并到开发中。接下来，我们为测试环境创建了一个发布分支。 但是，我们应该为不同的生命周期变更集做什么呢？

我们如何将发布分支合并到master分支中？ 我们应该如何在git分支上处理测试环境？

例如;

release 1.3.0 -具有一项功能，应在测试环境中保留2周，然后再进入生产环境

release 1.4.0 -有人添加了一项新功能，应在几天内用于生产环境。 （虽然release 1.3.0仍然有效。）

因此，测试环境将具有这两个功能，并且产品在几天后应具有最新的功能。 但是release 1.4.0分支具有这两个功能。 我应该将什么合并到生产分支中？

我们应该使用不同于git-flow的东西吗？ 您有什么建议？

Answer 1

那是很多不同的问题。 我将尝试回答我认为最重要的问题。

您现有的工作流程听起来像是颠覆之类的东西，在这种情况下，通常避免通过采摘来避免合并。 在git中，首选绝对是合并。

您给出的不合并分支的主要原因是您想使配置文件保持不同。 但这并不是您似乎想的那样大的问题。

假设您在Dev有一个配置文件config.json ，而在Test有一个不同的内容。

你可以这样做

# register a merge driver named 'ours' that uses the command 'true' to always return 0
git config --global merge.ours.driver true

git checkout Dev
echo 'config.json merge=ours' >> .gitattributes
git add .gitattributes
git commit -m 'Preserve config.json during merges'

git checkout Test
# copy the same commit, since we want the same setting in all branches
git cherry-pick Dev

# now, when you merge, config.json will be ignored
git merge Dev

完整的例子在这里

因此，这将使合并分支成为可能，这将解决您的第一个和第二个问题。 向此添加PR也应该可行，从而解决您的第三个问题。