混帐 |大型项目的分支模型

Question

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

问题在于我们的分支策略:我们正在使用 Vincent Driessen 的 branching model .每个人都为每个问题创建一个 feature branch 并在完成后将其 merge 回 develop (通过 pull request 并在 Stash 上进行审查后)。除此之外，我们为已完成但尚未发布的问题创建 bugfix 分支，为已发布的问题创建 hotfix 分支，为完成的 sprint 创建 release branches。在这种情况下，没有人会直接接触 develop 和/或 master。我们的前端团队使用 Sass 作为 CSS 预处理器。最后，我们有 TeamCity 来构建更改，它会在 master 分支上查找更改。

---

背景故事说得够多了吧？好吧，问题来了:假设我们在 sprint 中有 50 个问题(我们每个人 10 个)，而在 sprint 结束时，客户只想发布其中的 35 个(不用问为什么，这是客户).因此，我们需要以某种方式排除 15 个问题。大多数情况下，它们是前端问题。由于我们的设置，此时一切都在 develop 分支上。我们现在有几个选择:

• 从 develop 创建一个 release 分支 并恢复这 15 个问题(我们需要更新 TeamCity，或者将此分支 merge 回 master然后)。
• 将所有内容都放到 master 那里恢复(在这种情况下无需接触 TeamCity)。
• 将需要的问题挑选到 master 上(这也可能会导致很多冲突)。

但是两者都有这个限制:Sass-to-CSS操作。如果我们选择第一个选项，并且存在一些前端问题，那么肯定会发生冲突。如果我们选择第二个选项，我们就会失去对位置的跟踪，我认为这最终是一种滥用。

还有一个很大的全局限制:我们需要在 develop 上进行测试(所以，每个已完成的问题都需要在 develop 上进行测试，这不能更改)并且我们正在发布 master 上的内容(有一种方法可以在 TeamCity 中更改它，但没有人想更改它)。

问题是:当有一些改进和停顿同时发生时，我们如何继续使用Git？

如果您需要，我可以提供更多详细信息，请随时询问。

Answer 1

希望我能很好地理解您的问题。我认为第四种解决方案更适合您的情况:

• 像现在一样使用develop，把所有东西都放在那里，因为你必须在那里做测试
• 设置一个 production(或 release)分支 -> 这将是你的发布分支，至少现在是这样，直到你可以完全部署所有东西(如果你的客户愿意永远想要那个)
• 既然你说一切都在功能分支上，你可以很容易地将这些分支 merge 到 production 分支中，在它们在 develop 上测试之后。基本上 develop 是您的 qa 分支(用于测试目的)。这比在冲刺结束时挑选数十或数百次提交要好。

所以我的基本建议是在将功能分支 merge 到 develop 之后，不要删除它们，最终修复与该功能分支上的功能相关的错误，然后将分支 merge 到生产一个。

如果您认为有某些原因导致此方法不起作用(除了您必须更改发布分支配置这一事实之外)，请告诉我。