将大型Git/TeamCity项目的问题与4个版本合并

我和我的队友为一家软件供应商工作，为一个客户构建一个大型软件。许多开发人员使用Git进行源代码控制。我们有4个版本：

• 0.9：生产中
• 0.9.1：在客户处进行测试
• 1.0：由我们（软件供应商）进行测试
• 1.1：正在建造中

我们当前的工作实践是，例如，当您修复示例0.9.1中的错误时

• 拉取最新的0.9.1，然后将修复推到0.9.1
• 切换到1.0，拉最新的1.0，合并0.9.1，推到1.0
• 切换到1.1，拉最新的1.1，合并1.0，推到1.1

问题是，对于几十个开发人员来说，往往有多个人同时试图推动他们的修复。因此，人们通常会进行相同的合并，合并彼此的更改。例如：

• dev1将fix1推到0.9.1，拉1.0并开始合并
• 当dev1合并到1.0时，dev2将fix2推到0.9.1，拉1.0并开始合并他们自己的fix2，但也合并fix1
• 此外，还需要对1.1进行合并

我怀疑，由于所有这些痛苦，人们倾向于在本地机器上进行大量提交（未备份），然后进行大规模合并，比如每天一次或每两天一次，因此其他开发人员会针对过时的代码进行工作

我猜这个问题也会发生在其他基于Git的大型项目上。我想听听从事这类项目的人如何处理这个问题

当dev1合并到1.0时，dev2将fix2推到0.9.1，拉1.0并开始合并他们自己的fix2，但也合并fix1

---

如果dev2在推送时不是最新的，遥控器将拒绝它。在推送之前，您必须是最新的，除非它们是git push-f，这完全是另一个问题。

首先，您可能需要将项目“分区”到更多文件中。调制越多，用户越多。总的来说，这是一项非常困难的工作，在某些情况下几乎不可能做到

然后，根据项目大小，基本上有两个选项

• 对于较大的项目：使用
  我在这里没有经验，但如果你要做这件事，你应该自己做研究。无论哪种情况，这都是最大的项目所做的，例如
  在这种情况下，大多数开发人员应该不能再推送了，并且仍然会有同步工作的痛苦-但是如果您将项目划分为足够多的文件，以便每个开发人员一次只能在一个文件中工作，那么这可能会减少到零。加强第一步，这并不意味着简单地划分文件，而是意味着使每个文件尽可能独立，以便应用

• 对于较小的：坐标。沟通
  如果团队规模较小，分支和电子邮件就足够了。联系决定谁先做什么。通过分支，您不必一直合并。然后，如果有需要合并的重大冲突，您可以再次联系。这也不是很容易开始，但它的工作

  *

  如果您决定听从nvie的建议，请当心。至少在那个模型上是这样的