Git - 分支与多个遥控器

时间:2017-09-20 21:19:51

标签: git

我对git及其最佳实践相当新。当我看到这个例子时,我正在阅读文档:

$ cd grit
$ git remote -v
bakkdoor  https://github.com/bakkdoor/grit (fetch)
bakkdoor  https://github.com/bakkdoor/grit (push)
cho45     https://github.com/cho45/grit (fetch)
cho45     https://github.com/cho45/grit (push)
defunkt   https://github.com/defunkt/grit (fetch)
defunkt   https://github.com/defunkt/grit (push)
koke      git://github.com/koke/grit.git (fetch)
koke      git://github.com/koke/grit.git (push)
origin    git@github.com:mojombo/grit.git (fetch)
origin    git@github.com:mojombo/grit.git (push)

该文件继续提及:

  

这意味着我们可以从这些用户中获取贡献   容易。我们可能还有权推送到一个或多个   这些,虽然我们不能在这说明。

对于我(或团队)来说,在单独的远程存储库中拥有相同代码库的多个副本会有什么好处?这样做之间的区别是什么,只需为每个人设置一个单独的分支(这可能是不好的做法)无论如何,但是单独的回购似乎更糟糕了吗?

2 个答案:

答案 0 :(得分:2)

您必须了解每个克隆都已经拥有自己的一组分支。因此bakkdoor/mastercho45/master是两个不同的分支。它们可能具有相同的本地名称(master),并且可能具有相同的远程跟踪分支(origin/master,它们都推送到origin远程)但它们仍然是需要的单独分支单独管理。

如此有效,通过使用多个存储库,您只是在本地更远的层面上进行分支。但技术几乎相同。

当然,您实际谈论的是团队使用的distributed workflow。经典的工作流程是集中式工作流程,您可以在中间拥有一个每个人都可以访问的受保护的存储库。这适用于知道自己在做什么的团队。每个人都应该推动正确的事情,并且在协调良好的团队中,这非常有效。

对于开源项目,常见的工作流程是“集成管理器工作流程”。有限数量的开发人员可以对受祝福的存储库进行写访问。开发人员应该在其他地方(通常在他们自己的公共存储库中)发布他们提出的更改,然后提出拉取请求以获得合并的内容。最大的好处是这适用于所有类型的团队:因为访问中央存储库非常有限,任何人都无法搞砸那一个。开发人员,甚至是不受信任的开发人员,只能在他们自己的公共存储库中发布他们的更改 - 如果他们陷入困境,那么,这是他们的存储库,他们可以做任何他们想做的事。

另一个好处是,这可以更清楚地了解项目的“正典”。开发人员可以在自己的存储库中进行实验并更改所有内容,而不会影响中央存储库中的其他人。所以有更多的自由。当然,您也可以使用命名良好的分支机构名称和一个优秀的团队来做到这一点,但这更难。通常情况下,人们会回到这个工作流程,因为它工作得非常好 - 尤其是GitHub,这是一个以拉动请求为中心的平台。

答案 1 :(得分:0)

我看到的唯一好处是,您可以通过拉动他们的存储库来跟踪同事的工作。

但很快就会变得一团糟。

最常见的工作流程是使用分支。

通常情况下,团队成员在处理某项功能时不需要继续推动其更改。

仅在以下情况下才需要:

  1. 您希望在远程仓库上保留备份
  2. 您想与同伴分享作品
  3. 您想要在其他计算机上恢复工作
  4. 在功能分支上完成工作后,将其合并到主(主)分支。