SVN / Git如何管理分支机构

Question

我是一家小公司(6名开发人员)的技术负责人。我们目前使用SVN，在每个人都接受培训之后，我们正在慢慢地移植到Git。

目前，我们的客户是那些“扣动扳机”的分支整合。这意味着构建了一些模块或功能，然后，该功能位于一个分支中，直到客户端要求它运行为止。当它运行时，我们将分支合并到一个暂存环境中并进行测试。然后，一旦测试确认一切都正常工作，我们就将这些更改合并到主干道中，以便进行实时推送。

之所以这样做，是因为我们经常有很多并行开发，而且需求总是在动态变化。因此，为了隔离和控制去向，我们将每个模块或特性放在自己的分支中。

很长一段时间以来，我们在管理分支机构方面一直存在问题。因此，例如，我们可以构建一个具有A特性的分支。六个月后，客户端或开发经理最终会希望提前进行更改，如果他们中的任何一个记得的话。这就是我的问题所在。我有什么方法可以跟踪哪些分支已经被合并了？还是不合并？监视所有这些变化的一种集中的方式。

这可能是一个管理上的挑战，因为通常作为我公司的领导，我需要在几个平台上进行项目管理、代码、代码评审和集成。这里的线索不是筒仓，我们必须成为所有发展的一部分。因此，在任何时候，我的ToDo列表上都会有多达7-10个不同的项目，而集成和分支管理可能会从裂缝中溜走。

Answer 1

如果您有很多并行开发，请考虑使用主分支和特性切换。

它确实需要一些额外的纪律，以确保构建工作(即使功能切换代码是不完整的)和创建，使用，然后清理功能切换。这可以通过使用静态分析工具和自动化测试在一定程度上抵消这一点，这两种测试都可以证明功能是有效的，但同时也可以确保功能切换时不可用。

不过，合并的好处是，合并不是问题，因为只有很少的分支，而且那些确实存在的分支很快就会被合并。此外，这也移除了许多分支管理。它还将部署与特性发布分离开来。这可能是一个非常好的销售给你的客户/营销部门，以确保他们的稳定性，和可用性增强，因为新的功能可以禁用，如果他们有意外的问题。

如果您有危险的不利环境或需要支持多个发布线，请使用分支机制来分离一个发布分支。这个分支可以有不完整的，或不可释放的特征从它移除。这很好，因为分支永远不会合并回主分支。缺陷修复可以在主线上进行工程，并被选中到发布分支。

Answer 2

我可以想出两种方法来处理你的场景

1. 合并后删除分支:一旦合并了分支，就删除它。这样你就会知道有一天所有的枝条都会活下来。删除-分支
2. 合并后重命名分支:如果您认为可能需要对分支进行以后的引用，而不是删除分支，则重新命名分支。重命名-分支