问题
I am new to Git so bear with me.
I have a Git repository (on GitHub) and I have lots of coders who are inexperienced with Git. When I hire them, I ask them to make a pull request towards my repository so I can review their changes before I merge. At the moment my biggest problem is that often I merge changes into my repository after they fork it, but before they make their pull request, meaning that merging their pull request overrides an earlier commit.
Is there a way for me to ensure that this will not happen apart from telling them to avoid the problem?
回答1:
The way to ensure that this will not happen is to reject any commit which cannot be applied in a fast-forward manner.
But nothing prevent a user to submit a pull-request without first updating his/her own fork.
A correct pull request should be applied in a fast-forward manner, which means a contributor should first rebase his/her work on top of the latest commit of the destination repo (ie git pull --rebase), before making the pull request.
In other words, they should first integrate your other changes you have merged in their own local repo, test that their contribution is still working, before the pull request.
If they do that, there won't be any issue with overriding earlier commits.
If there is, you simply reject the pull request, asking the contributor to rebase the local repo first.
回答2:
The hard way: Ask them to create a (local) branch before merge.
The easy way: Let's forget "how to avoid the problem", tell them how to fix it. In git, we have git reflog that can rollback (almost) any changes.
P.S. Merging don't "override" an earlier commit. You can use git log ; git reset to fix (most) of it even if you don't have reflog.
来源：https://stackoverflow.com/questions/12445392/pull-requests-overriding-earlier-commits