Git | 一个大型项目的分支模型

Question

Git | 一个大型项目的分支模型

7

我们的团队有三个后端开发人员和两个前端开发人员。我们使用 Git 作为版本控制系统，Jira 用于问题和项目跟踪，Stash 作为 Git 存储库。最后，我们使用 SourceTree（带有 git-flow）作为 Git 客户端。

问题是关于我们的分支策略：我们使用 Vincent Driessen 的分支模型。每个人为每个问题创建一个 feature 分支，并在完成后将其合并回 develop（通过拉取请求并在 Stash 上审核后）。除此之外，我们为已完成但尚未发布的问题创建 bugfix 分支，为已发布的问题创建 hotfix 分支，并为已完成冲刺创建 release 分支。在这种情况下，没有人直接操作 develop 和/或 master。我们的前端团队使用 Sass 作为 CSS 预处理器。最后，我们有 TeamCity 来构建更改，并查找 master 分支上的更改。

足够的背景故事了吧？那好吧，问题在这里：假设我们的冲刺中有 50 个问题（每个人有 10 个），并且在冲刺结束时，客户只想发布其中的 35 个问题（不需要问为什么，这是客户的要求）。因此，我们需要以某种方式排除 15 个问题。大多数是前端问题。由于我们的设置原因，在此时一刻，所有内容都在 develop 分支上。现在我们有几个选择：

从 develop 创建一个 release 分支并还原这 15 个问题（我们需要更新 TeamCity 或之后将此分支合并回 master）。
将所有内容放到 master 上并在那里还原（在这种情况下，无需触及 TeamCity）。
将所需的问题挑选到 master 上（这可能会导致很多冲突）。

但两者都有一个限制：Sass 到 CSS 的操作。如果我们选择第一种方法，并且有一些前端问题，则肯定会发生冲突。如果我们选择第二种方法，则我们会失去对每个位置的追踪，我认为最终这是一种滥用。

还有一个重要的全局限制：我们需要在 develop 上进行测试（因此，每个已完成的问题都需要在 develop 上进行测试，这不能改变），而我们将发布在 master 上（有一种方式可以在 TeamCity 中更改，但没有人想要更改）。

这个问题是：当有一些改进和停顿时，我们如何持续使用Git？如果需要更多细节，请随时问我。

- Gökay Gürcan

1

你是否在开始冲刺之前就知道要在发布中包含哪些问题，还是这是在最后决定的？ - poke

你不能在修复错误和功能分支中进行测试吗？尽量保持它们的最新状态，当问题完成（开发+测试）并决定发布更改时，将其合并到主分支。 - Jehof

@Jehof，很遗憾，我们的测试环境只检查develop分支上的更改。否则会很混乱。 - Gökay Gürcan

但如果你只在开发阶段测试，并且只在冲刺的最后选择实际要包含的功能，这也意味着交付的功能从未单独测试过，而总是与其他功能集合在一起。这很糟糕，你应该向客户沟通，以便留给你更多时间稳定要交付的确切功能集。 - poke

没错。我们的设置有点奇怪，限制了我们的工作。但这就是我们所拥有的。是的，我们需要一起测试它们，以确保它们都正常工作。有时候，改变一行代码会导致所有东西都崩溃，我是说真的，所有东西都崩溃了。 - Gökay Gürcan

显示剩余3条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Raul Rene · Accepted Answer

希望我理解了您的问题。针对您的情况，我认为第四种解决方案更可行：

与过去一样，使用develop分支，将所有内容放在其中，因为您必须在此处进行测试
设置一个production（或release）分支 -> 这将是您的发布分支，至少现在是如此，直到您可以完全部署所有内容（如果您的客户确实需要）
由于您说所有内容都在特性分支上，因此您可以在在开发分支上测试后轻松地将这些分支合并到production分支中。基本上，develop是您的qa分支（用于测试）。这比在Sprint期末挑选数十或数百个提交要好。

因此，我基本上建议在将特性分支合并到develop之后，不要删除它们，而是在该特性分支上进行与bugfixing相关的工作，然后将该分支合并到production分支中。

请告诉我，如果您认为此方法不起作用的原因（除了您必须更改发布分支配置）。