我开始在一家新使用git的公司工作。我需要一个好的推荐。首先，我想谈谈当前的工作流程。
该团队的工作流程与常规的git基础有很大不同。分支机构为
Local (feature/hotfix branch from Dev) -> Dev -> Test -> Prod
环境
Dev -> Test -> Prod
- 每个分支都有不同的配置文件(目前还没有解决方案。但我会先解决这个问题)，因此，我们无法合并分支
- 开发人员正在开发本地(功能/修补程序分支)，并将他们的推送合并到开发人员分支中，并在开发人员环境中发布他们的版本(只是补丁版本在增加(1.0.xxx)，我知道这不是一件好事。)
- 然后，他们在测试分支中挑选自己的更改。而且，他们在测试环境中发布了一个新版本。UAT在这里快乐
- 当开发人员想要将他们的更改发布到生产环境中时，他们也会精心挑选他们的更改。并在prod环境中发布新版本
这里的第一个问题是，我们不能很好地观察分支的历史，因为由于配置文件的原因，我们无法合并分支。
第二个问题是，有些更改应该在测试环境中停留1-2周，更改的寿命可能很长，也可能很短。
第三个问题，我们不能使用git功能，比如合并和拉取请求。我们想使用PR进行代码审查等等。这对我们来说很重要。
我可以说，在这个场景中，部署过程和版本控制系统是混合的。因此，我们希望使用类似git flow的东西。尽管如此，我们希望保留这三个环境(开发、测试和生产)，主要目标是合并分支并使用pull请求
比方说，我们只有发展和掌握分支。开发人员处理功能分支。并将它们的特点融合到发展中。接下来，我们为测试环境创建了一个发布分支。但是，对于不同的寿命变化集，我们应该怎么做呢？
我们应该如何将发布分支合并到主分支？我们应该如何处理git分支上的测试环境？
例如；
release 1.3.0-有一个特性，应该在测试环境中停留2周，然后应该进入生产环境
release 1.4.0——有人添加了一个新功能，应该在几天后用于生产环境。(而release 1.3.0仍然有效。)
所以，测试环境将具有这两个功能，而prod应该在几天后具有最新的功能。但release 1.4.0分支同时具有这两个特性。我应该将什么合并到生产部门？
我们应该使用与git流不同的东西吗？你的建议是什么？
这是很多不同的问题。我会尽力回答我认为最重要的一个问题。
您现有的工作流程听起来像是受到颠覆之类的启发，在颠覆中，通过挑选樱桃来避免合并是很常见的。在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也应该有效，可以解决您的第三个问题。