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. 然后他们挑选他们的变化进入测试分支。并且，他们在测试环境中发布了新版本。 UAT在这里很开心。
4. 当开发人员想要将他们的更改发布到生产环境中时，他们也会挑选他们的更改。并在prod环境中发布新版本。

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

第二个问题是一些变化应该在测试环境中保持1-2周两周，变化可以有长或短的寿命。

第三个问题，我们不能使用像合并和拉取请求这样的git功能。我们希望使用PR进行代码审查等。这对我们很重要。

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

比方说，我们只开发和掌握分支机构。开发人员在功能分支上工作。并将其功能合并到develop中。接下来，我们为测试环境创建了一个发布分支。但是我们应该为不同的终身改变集做些什么呢？

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

例如;

release 1.3.0 - 有一个功能应该在测试环境中保持2周，然后应该去生产环境

release 1.4.0 - 有人在几天内添加了一个应该用于生产环境的新功能。 （而release 1.3.0还活着。）

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

我们应该使用与git-flow不同的东西吗？你的建议是什么？

Answer 1

这是很多不同的问题。我会尽力回答我认为最重要的那个。

您现有的工作流程听起来像颠覆这样的东西，通常避免合并而不是挑选。在git中，首选是合并。

您没有合并分支的主要原因是您希望保持配置文件不同。但这并不像你想象的那么大。

假设您在config.json中有一个配置文件Dev，在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

Full example here

因此，这应该可以合并分支，这应该解决您的第一个和第二个问题。添加PR也应该有效，解决你的第三个问题。