Github的工作流程和拉請求顯示不希望犯

Question

在我們的業務，我們有以下設置（巨大的簡化版本），非常標準：

• 的主分支，它通過一個鉤更新現場環境。
• 測試分支，用於QA，UA，它以相同的方式更新測試環境。

該回購託管在GitHub上。

工作流通常如下：

• 從主
• 拉創建分支例如Ticket1到特定的票
• 做工作的工作，測試本地
• 提交併推送分支Ticket1
• 合併Ticket1進入測試通過github上拉的請求，這使我們能夠做出一個同行代碼審查等。

太漂亮了。當向測試分支提出pull請求時，我們有時會遇到，在pull請求中，github顯示更多的提交，那些開發人員認爲應該執行的提交。經過調查，我們已經實現了至少一個特定的情況下（這可能不是唯一的一個），當出現這種情況：

1. 開發人員A做了一些變更進行測試，通過質量和UA，以及它們與主合併。
2. 開發者B做了一些更改。與主人合併時，會有衝突。開發人員B解決衝突並在新的提交中將衝突解決方案提交給ID，例如， 1234567
3. 開發人員A開始工作到另一張票：他從主人拉（因此拉1234567提交），創建一個分支，提交，推，當在GitHub上的拉請求合併他的分支到測試GitHub想要合併其提交加1234567.這讓他感到害怕，因爲他不知道有關該特定提交的任何內容。

我搜索過類似的問題，我已經發現至少有：

• 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

他們處理了一個命令行的解決方案（基本上使用'rebase'）。然而，他們沒有解決我們的根本問題，那就是如何避免這種情況發生。我想知道爲什麼會發生這種情況，也就是說，我們知道發生時發生了，但我們不知道是因爲我們的工作流中存在根本性缺陷，還是因爲我們錯過了某些關於github如何創建請求的請求。

這肯定會發生在你之前。你如何解決？

Answer 1

我猜你有一個程序性'鎖定'問題，並且各個門票分支及其合併點的起點已經在拉點和最終合併點之間重疊。

開發人員認爲他們已完成拉取請求中的ticket1，但實際上不應該啓動ticket2的分支，直到合併&修復處於[小時/天后？]。否則，修正將不會在ticket2的開始處顯示。然後，當ticket2被拉動時，它仍然沒有修復，所以看起來它需要重新應用。

假設您想要一個線性的票據合併循環序列，開發人員需要重新獲取主服務器（在所有已同意的修復程序中！），然後在發出其請求之前進行重新綁定。

使用gitk或類似工具可以看到圍繞這些問題之一的所有分支，並檢查時間戳和您的審查會議時間，以查看這是否是隱藏的死區。