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?
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.
