如何管理提交者的层次结构（如 Linux 内核开发）
我是一个拥有 GitHub 存储库的项目的提交者。我有一个小开发团队，他们无法读取或提交该存储库。我想设置一个他们可以提交的 git 服务器，它是 GitHub 存储库的克隆。当他们提交时，我会对其进行审查，有时进行编辑，然后推送到 GitHub 存储库。
我的问题是，由于我有时会更改他们的提交，因此将更改从 GitHub 拉回到我的克隆服务器以便每个人的历史记录都不会混乱的最佳工作流程是什么？
编辑：澄清一下，我并不一定意味着提交将被编辑。但我可能需要删除/拒绝一些提交的提交（并且可能创建新的提交来改进它们）。这将如何影响我下游的开发人员？
I'm a committer on a project with a GitHub repo. I have a small team of developers who can't read from or commit to that repo. I'd like to setup a git server they can commit to that is a clone of the GitHub repo. When they make commits, I will review them, sometimes make edits, then push to the GitHub repo.
My question is, since I'll sometimes be altering their commits, what is the best workflow for pulling changes from GitHub back to my clone server so that everyone's history doesn't get messed up?
EDIT: To clarify, I don't necessarily mean that commits will be edited. But I may need to delete/reject some submitted commits (and maybe create new ones that improve them). How will that affect the developers downstream of me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我没记错的话，Linux 的管理方式与您提议的有点不同，因为大量开发人员积极为各种子系统做出贡献。
每个主要的内核子系统都有一个“副官”，负责协调对该子系统做出贡献的开发人员的提交。每个副官都保证他们的子开发人员的质量，并在他们准备好从他那里进行更改时告诉 Linus。 Linus 是唯一有权提交“主”存储库的人，然后一次拉取他们的更改。如果乔中尉和鲍勃中尉发生冲突，他会告诉乔从鲍勃那里拉出来并负责合并，然后他会再次从乔那里拉出来。
对于你的情况，我认为你所描述的情况是理想的。所有开发人员都可以拉/推的公共远程存储库，这使他们能够处理冲突和合并。除了合并提交之外，实际上没有任何需要更改提交，这应该为您完成。如果您需要更改代码，您可以创建新的提交并将其推送到公共 git 存储库以供开发人员下载。
我不知道是否有任何安全的方法来更改多个存储库中存在的提交。一旦你这样做，你的存储库就会出现分歧，如果没有 跳过障碍。
If I recall correctly, Linux manages things a bit differently than you're proposing, due to the massive number of developers actively contributing to various subsystems.
Each major kernel subsystem has a "lieutenant", responsible for wrangling the commits of the developers contributing to that subsystem. Each lieutenant vouches for the quality of their sub-developers, and tells Linus when they have changes ready from him to pull. Linus, the only person with commit access to the "master" repo, then pulls their changes one at a time. If there are conflicts from Lieutenants Joe and Bob, he'll tell Joe to pull from Bob and take care of the merge, then he'll pull again from Joe.
For you situation, I think what you describe is ideal. A public remote repo that all your developers can pull/push to, which allows them to handle conflicts and merges. There isn't really any need to alter the commits beyond merging them, which should be done for you. If you need to change the code, you can create fresh commits and push them to the public git repo for your developers to pull down.
I don't know if there is any safe way to alter commits which exist in several repositories. As soon as you do this, your repositories have diverged and you're not going to be able to push/pull without jumping through hoops.