GitHub是否會允許“另一個分支的分支”的合並或變基？

Question

我有一個獨特的場景，我正在與另一個人一起工作一個項目（包含一個GitHub存儲庫），並且負責設計，一些開發和代碼審查+ PR合並。 我想在這里盡可能地堅持使用GitFlow，而我只想成為可以將功能分支中的PR合並到開發中的人。 因此（至少暫時）我要使用的身份驗證模型是：

• 我具有對master和develop讀/寫訪問權限
• 另一個開發人員只有讀取權限才能develop

因此，現在我們處於有趣的流程中：

1. 在其他開發切開一個特性分支（比如feature/12345 ）關閉的develop和它的工作了幾天，然后推着變化的GitHub
2. 我花了幾天的時間進行代碼審查他的工作，但我不想讓他feature/23456 ，所以我讓他從他的第一個功能分支中刪除了下一個功能分支（例如feature/23456 ），開始工作。
3. 在接下來的幾天里，我開始進行代碼審閱feature/12345 ，對其進行了一些更改，然后推送了這些更改。 同時，他從事feature/23456 。
4. 滿意feature/12345 ，我把它合並進develop ，問他我的變化拉進他的feature/23456 。

他將能夠創造一個PR合並feature/23456到develop ，或將這種情況下搞砸了GitHub的“分支的分支”？ 我將能夠實際進行合並，還是需要進行某種類型的變基（如果是，則此命令的外觀如何）？

Answer 1

如果您的同事還沒有推feature/23456到GitHub上，他應該拉最新develop ，並在它上面的底墊特性分支：

• 檢出feature/23456
• 執行git rebase develop

就是這樣，現在他的功能分支似乎總是從develop的頂部開始增長。

如果不能使用rebasing，最有可能的是，git可以在沒有附加魔術的情況下很好地處理另一個分支的合並分支，但是不能肯定地說。

如果由於某種原因事情變壞了，總會有愚蠢而不優雅的解決方案。 它總是可以創建新的分支從develop和簡單的cherry-pick所有必要提交feature/23456進去，使“新鮮重復”它讓事情變得簡單。