Github工作流程和请求显示不需要的提交 [英] Github workflow and pull requests showing unwanted commits
问题描述
在我们的业务中，我们有以下设置（非常简化的版本），非常标准：
回购托管在GitHub上。
工作流程通常如下：
- 从主设备拉出
- 创建分支，例如Ticket1处理特定的票据
- 完成工作，在当地进行测试
- 提交并推送分支Ticket1
- 通过github中的pull请求将Ticket1合并到测试中，这允许我们进行同行代码审查等。
太。当向测试分支提出pull请求时，我们有时会遇到，在pull请求中，github显示更多的提交，那些开发人员认为应该执行的提交。经过调查，我们发现至少有一个特殊情况（可能不是唯一的情况）：
- 开发人员A进行了一些更改测试，传递QA和UA，并将它们与主合并。
- 开发人员B进行了一些更改。与主人合并时，会有冲突。开发人员B解决冲突并在新的提交中将冲突解决方案提交给ID，例如，开发人员A开始工作到另一个工单：他从主服务器拉出（因此拉动1234567提交），创建分支，提交，推送以及在GitHub上执行拉取请求时合并他分支到测试中GitHub想合并它的提交和1234567.这让他感到害怕，因为他对这个特定的提交并不知情。
我搜索了类似的问题，至少发现了：
它们处理命令行解决方案（基本上使用'rebase'）。然而，他们没有解决我们的根本问题，那就是如何避免这种情况发生。我想知道为什么会发生这种情况，也就是说，我们知道发生这种情况的时间，但我们不知道这是因为我们的工作流程中存在根本性缺陷，还是因为我们错过了关于github创建了拉取请求。
当然，这肯定发生在你之前。你怎么处理它？</ p>
我猜你有一个程序性'锁定'问题，各分支机构及其合并点之间已经在拉点与最终合并和重合之间重叠。定点。 开发人员认为他们已完成拉取请求中的ticket1，但实际上不应该开始ticket2的分支直到merge&修复是在[小时/天之后？]。否则，修正将不会在ticket2的开始处显示。然后，当ticket2被拉动时，它仍然没有修复，所以它看起来像需要重新应用。
假设你想要一个线性序列票合并循环，开发人员需要重新获取主人（在所有同意的修正中！），然后在他们发出他们的请求之前进行变身。
使用gitk或类似的工具，可以看到围绕这些问题之一的所有分支，并检查时间戳和您的审查会议时间，以查看这是否是隐藏的死区。
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?
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.
这篇关于Github工作流程和请求显示不需要的提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
