0

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

团队的工作流程与常规的 git 基础有很大不同。树枝是

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

环境

Dev -> Test -> Prod
  1. 每个分支都有不同的配置文件（还没有解决方案。但我会先解决这个问题）因此，我们不能合并分支。
  2. 开发人员正在本地（功能/修补程序分支）上工作并将他们的推送合并到 Dev 分支并在 Dev 环境上发布他们的版本（只是补丁版本正在增加（1.0.xxx），我知道这不是一件好事。）
  3. 然后他们将他们的更改挑选到测试分支中。并且，他们在测试环境上发布了一个新版本。UAT 在这里很开心。
  4. 当开发人员想要将他们的更改发布到生产环境中时，他们也会挑选他们的更改。并在 prod 环境上发布新版本。

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

第二个问题是一些更改应该在测试环境中保留 1-2 两周，更改的生命周期可以长也可以短。

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

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

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

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

例如;

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

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

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

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

4

1 回答 1

0

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

您现有的工作流程听起来受到了颠覆之类的启发，在这种情况下，通常通过挑选来避免合并。在 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

完整的例子在这里

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

于 2019-02-12T20:09:42.217 回答