开源项目中git存储库的最佳实践

时间:2009-09-05 03:22:15

标签: linux git version-control

我正在为Github上托管的一个相当小的开源项目做出贡献。所以其他人可以利用我的工作,我在Github上创建了自己的分支。尽管Github选择了术语,但我不希望完全偏离主要项目。但是,我并不期望或希望我的所有工作都被接受到主存储库中。但是其中一些已经合并到主存储库中,我希望这会继续下去。我遇到的问题是如何最好地保持我们的两棵树处于可以轻松共享代码的状态。

我遇到或将要遇到的一些情况包括:

  • 我提交稍后接受的代码 进入主存储库。当我拉 将来从这个存储库, 我的提交在我的复制中重复 库中。
  • 我提交的代码从未被接受到主存储库中。当我将来从这个存储库中取出时,这两棵树已经发散并且很难修复它。
  • 另一个人出现并将他们的工作建立在我的存储库上。因此,我应该尽可能避免更改我推送的提交,例如使用git rebase。
  • 我希望将代码提交到主存储库。理想情况下,我的更改应该很容易转换为可以直接且干净地应用于主存储库的补丁(理想情况下使用git format-patch)。

据我所知,有两种或三种方法可以解决这个问题,但其中没有一种方法效果特别好:

  • 经常运行git rebase以保持我的更改基于上游存储库的头部。通过这种方式,我可以消除重复的提交,但往往不得不重写历史记录,给想要从我的工作中获取工作的人带来问题。
  • 经常将上游存储库更改合并到我的中。这在我的结束时工作正常,但似乎并不容易将我的代码提交到上游存储库。
  • 使用这些和可能的git cherry-pick的一些组合来保持秩序。

在这种情况下,其他人做了什么?我知道我的情况类似于各种内核贡献者和Linus的主存储库之间的关系,所以希望有很好的方法来处理这个问题。虽然我对git很新,所以还没有掌握它的细微差别。最后,特别是由于Github,我的术语可能不完全一致或正确。随意纠正我。

1 个答案:

答案 0 :(得分:17)

我从类似情况中学到的一些提示:

  • 为上游作者的工作设置远程跟踪分支。
  • 经常将更改从此跟踪分支拉到您的主分支。
  • 为您正在处理的每个主题创建一个新分支。这些分支通常应该只是本地的。当您从上游变为主变更时,请重新定义主题分支以反映这些变化。
  • 当您完成某些主题工作后,请合并到主人。通过这种方式,从您的工作中获取工作的人不会看到太多重写的历史记录,因为重新定位发生在您的本地主题分支中。
  • 提交更改:您的主分支基本上是一系列提交,其中一些与上游相同,其余的都是您的。如果你愿意,后者可以作为补丁发送。

当然,您选择的分支名称和遥控器是您自己的。我不确定这些情况是否详尽无遗,但它们涵盖了我的大部分障碍。