2

我检查了一个我想要工作的 git 项目。我没有推送权限，所以我将向上游维护者提交补丁。我想创建自己的分支，并在该分支上与其他几个人合作。工作完成后，我想根据主项目的当前负责人重新设置我的分支并将补丁发送给上游维护者。问题是：如何组织在一个分支上工作的一组人之间的协作？

目前我使用以下设置：

  • 我有自己的 git 服务器，我在上面保存了 repo 的裸副本。
  • 我将我的工作分支存储在该服务器上
  • 其他开发人员将他们的更改推送到服务器上的该分支并提取其他人所做的更改，因此服务器充当所有在分支上工作的人的中央存储库
  • 对 master 所做的更改是从项目的上游存储库中提取的。
  • 如果需要，可以将 Master 推送到我的服务器

我认为这是一个很好的设置，但我意识到如果我决定将我的分支重新定位到来自上游的当前主服务器，那么一切都会中断。如果我将重新设置的分支推送到我的本地服务器，它最终会成为其他人的灾难，所以显然这不是一个正确的设置。我和我的朋友讨论过这个问题，他指出问题是由于使用我自己的本地服务器作为所有开发人员的中央服务器造成的，就好像它是一个颠覆存储库一样。因此，虽然我认为我们意识到了问题的根源，但我们并没有想出一个正确的方法来组织我们的 git 工作流。这应该怎么做？

4

1 回答 1

1

你的每个同事都应该为他们的每一个小迭代创建微分支[又名特性分支]（从你的主分支；你也应该这样做），他们可以随时将它们推送到你的服务器以允许它们被看到。随着每个微迭代的完成，他们（和您）将在您的主分支之上重新定义该迭代，以查看它是否仍在工作并准备好与您的主分支集成。

这里有一场比赛来保持迭代的简短和小，以便它们“正常工作”并且是可接受的，并合并或快速转发到您的主分支。在某些情况下，不同的迭代会相互作用，适当的开发人员可以使用推/拉的微分支进行协作，以避免内讧；-)

如果在开发中有很多交叉运行的功能，那么您可以使用git help workflows类似于 Git 维护者使用的工作流（），Master <- Next <- pu（潜在更新）<-contributor 分支，pu 在之后倒带每个周期，贡献者都会对重新缠绕的分支进行全新的观察，以了解他们的更改如何适应更大的整体。

补丁提交

一旦您在“主”分支中完成了一项工作，您应该再次获取/拉取上游主服务器（以及他们可能拥有的任何发布候选者）并在它们之上重新调整您的更改以真正保持最新。

现在，您将使用 准备来自您的分支的补丁系列git format-patch，很可能已经准备了一封介绍该系列的求职信。然后使用git send-email将它们发送进来。尽管将它们发送给自己，并查找上游项目提供的任何说明，但还是值得练习的。例如Git 的 SubmittingPatches。

于 2013-01-19T11:36:38.480 回答