如何管理提交者的层次结构(如Linux内核开发人员)

时间:2010-11-12 16:04:02

标签: git project-management github dvcs

我是一个带有GitHub仓库的项目的提交者。我有一个小团队的开发人员,他们无法读取或承诺该回购。我想设置一个他们可以提交的git服务器,它是GitHub repo的克隆。当他们提交时,我会审查它们,有时会进行编辑,然后推送到GitHub仓库。

我的问题是,由于我有时会改变他们的提交,将GitHub的更改提取回我的克隆服务器的最佳工作流程是什么,这样每个人的历史都不会搞砸了?

编辑:澄清一下,我并不一定意味着将对提交进行编辑。但我可能需要删除/拒绝一些提交的提交(并且可能会创建新的提交它们)。这将如何影响我下游的开发人员?

1 个答案:

答案 0 :(得分:7)

如果我没记错的话,由于大量的开发人员积极参与各种子系统,Linux的管理方式与你提出的方式略有不同。

每个主要内核子系统都有一个“中尉”,负责处理为该子系统做出贡献的开发人员的提交。每个中尉都要保证他们的副开发人员的质量,并告诉Linus他们有什么变化准备从他拉。 Linus是唯一一个拥有“master”仓库访问权限的人,然后一次提取一个。如果中尉Joe和Bob发生冲突,他会告诉Joe从Bob那里撤回并照顾合并,然后他会再次从Joe那里撤回。

对于你的情况,我认为你所描述的是理想的。所有开发人员可以拉/推的公共远程仓库,允许他们处理冲突和合并。除了合并之外,没有必要改变提交,这应该为你完成。如果您需要更改代码,您可以创建新的提交并将它们推送到公共git仓库,供开发人员下载。

我不知道是否有任何安全方法可以更改多个存储库中存在的提交。一旦你这样做,你的存储库就会出现分歧,你不能在没有jumping through hoops的情况下推/拉。