4

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?

svick
  • 236,525
  • 50
  • 385
  • 514
noah
  • 21,289
  • 17
  • 64
  • 88
  • It's never a good idea to alter commits that have been pushed/pulled. – user229044 Nov 12 '10 at 16:07
  • 1
    Well, in this situation, what is the alternative? Linux kernel development functions like this. There are several levels of committers before you get to Linus. How do those at the bottom of the tree pull down changes accepted at the top? – noah Nov 12 '10 at 16:16
  • 1
    I don't believe Linus alters the commits coming in, they're just merged by his lieutenants. – user229044 Nov 12 '10 at 16:21
  • One possibility might be to let a tool like gerrit handle some of that stuff... In any case, once you decide there's going to be some potential for commits to be modified in any way (rejected, edited, rebased), you're depending on integrators and developers to know what to do. Developers need to keep things on topic branches until they're merged, then just grab the version with the commits merged (resetting if necessary), and integrators need to be selective about pulling (making sure never to accidentally pull a duplicate commit if a dev forgets to be careful). Can't see any way around that. – Cascabel Nov 12 '10 at 16:33

1 Answers1

7

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.

Community
  • 1
  • 1
user229044
  • 232,980
  • 40
  • 330
  • 338