2

我和我的队友为一家软件供应商工作，为客户构建一个大型软件。数十名开发人员使用 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 的大型项目上。想听听从事过此类项目的人如何处理此问题。

4

2 回答 2

0

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

然后，您基本上有 2 个选项，具体取决于项目大小。

  • 对于更大的项目：使用拉取请求。

    我在这里没有经验，但如果你在这方面使用Linus 或 GitHub ，你应该自己做研究。无论哪种情况，这都是最大的项目所做的，例如jquery。

    在这种情况下，大多数开发人员应该无法再推送，并且仍然会有同步工作的痛苦- 但是如果您将项目划分为足够多的文件以便每个开发人员一次工作，这可能会减少到零。重新执行第一步，这并不意味着简单地划分文件，而是意味着让每个文件尽可能独立，这样你就可以应用单元测试了。

  • 对于较小的：坐标。分支*。交流。

    如果团队很小，分支和发送电子邮件就足够了。联系以决定谁先做什么。通过分支，您不必一直合并。然后，如果发生需要合并的大冲突，您会再次联系。这也不是很容易开始，但它确实有效。

    * 如果您决定听从 nvie 的建议，请当心。该模型至少存在一个大缺陷。

于 2013-12-02T16:07:48.267 回答
0

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

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

于 2013-01-08T07:01:53.347 回答