问题
In our business we have the following setup (hugely simplified version), pretty standard:
- A master branch, which updates the live environment through a hook.
- A test branch, used for QA, UA, which updates a test environment in the same way.
The repo is hosted on GitHub.
The workflow is usually as follows:
- Pull from master
- Create a branch e.g. Ticket1 to work on the particular ticket
- Do the work, test locally
- Commit and push branch Ticket1
- Merge Ticket1 into test through a pull request in github, which allows us to make a peer code review, etc.
So pretty standard too. When making pull requests to the test branch we're encountering sometimes, in the pull request, github show more commits that the ones that were supposedly done by the developer. Upon investigation we have realised at least one particular case (which may not be the only one) when that happens:
- Developer A makes some changes to test, pass QA and UA, and they are merged with master.
- Developer B makes some more changes. When merging with master, there's a conflict. Developer B solves the conflict and commits the fix to the conflict in a new commit with id e.g. 1234567
- Developer A starts working into another ticket: he pulls from master (therefore pulling the 1234567 commit), creates a branch, commits, pushes and when making the pull request on GitHub to merge his branch into test GitHub wants to merge its commits plus 1234567. Which scares him as he doesn't know anything about that particular commit.
I've searched for similar questions and I've found at least:
- Why does my GitHub pull request have two commits?
- How to do a pull request in GitHub with only the latest commit in the master branch of my forked repository
- Send a pull request on GitHub for only latest commit
Which they dealt with a command line solution (basically using 'rebase'). However they don't dealt with the root problem for us, that is how to avoid for that to happen. I would like to know why that happens, meaning, we know when that happens, but we don't know if it is because there's something fundamentally flawed in our workflow or because we're missing something regarding how github creates the pull request.
Surely this must had happened to you before. How do you deal with it?
回答1:
I'm guessing that you have a procedural 'locking' problem, and the start points of the various ticket branches and their merge points have become overlapped between the pull point and the final merge & fix point.
The developers thinks they have finished ticket1 at the pull request, but shouldn't actually start ticket2's branch until the merge & fix is in [hours/days later?]. Otherwise the fixes won't actually show at the start of ticket2. Then when ticket2 is pulled it still doesn't have the fix in it so it looks like it needs to be re-applied.
Assuming you want a linear sequence of ticket merge loops, the developers need to re-fetch master (with all the agreed fixes in!), and do a rebase, just before they issue their pull request.
Use gitk or similar to visualise all your branches around the point of one of these problems, and check the time stamps and your review meeting times to see if that is the hidden dead-zone.
来源：https://stackoverflow.com/questions/11880297/github-workflow-and-pull-requests-showing-unwanted-commits