我們可以將開發分支合併到git-flow中的Feature分支中嗎？

Question

1. ，我們可以將其合併開發分支到特性分支在混帳流？

2. 如下圖所示，有兩個功能分支（A（紅色）和B（藍色）），由兩位開發人員分配。當B需要A的部分代碼時，是否允許那A推開發進行編碼，然後B把它從開發？

3. 合併開發分支，它沒有合併，但覆蓋，爲什麼，以及如何解決它？

Answer 1

1）參賽隊可以在此不同的一些認爲「不必要合併」創造歷史很醜，可是我看到合併develop到功能分支沒有問題。如果您認爲它使歷史更清晰（並且尚未推送功能分支），則可以選擇將功能分支向前重新綁定，但這可能會中斷功能分支上的中間提交。

2）不完整的功能不應合併到develop。 develop應隨時準備發佈。乾淨地在功能分支之間共享變化是非常棘手的（並且，對於具有小故事/功能的合理靈活的方法，通常是不必要的）。大多數做法都涉及到一些妥協。見下文。

3）我不確定爲什麼你會看到這種行爲;可能需要有關您如何嘗試合併的更多信息。通過檢查出來的分支，做一些像git reset --hard HEAD^

---

好了，所以如何，如果你有共享代碼（如果這是在沒有已被推合併完成最好的），您可以撤消合併？那麼，如果你接受我的建議，不要將A合併到develop，你可能會認爲「我可以直接合並A到B？」。那麼，這比直接合併到develop好，但意味着B不能安全地合併到develop，直到A已被（因爲它將進行部分實施A）。

如果A沒有被按下，那麼你可能會做的A一個互動變基到移動上B取決於高達A開始的更改，然後重訂B到有共同變化的提交。但這可能涉及到分割提交，並可能創建中斷狀態，並取決於沒有被推動的分支（或者每個人都必須從上游轉賬中恢復）......所有這些都不容易做到。

另一種選擇是從A挑選到B的變化。這也是一種重新綁定操作，但它保留了所有現有的提交（因此不必擔心是否推送了任何內容）。但是，如果共享變更處於也存在其他變更的提交中，它仍然不是那麼容易;當將這些功能合併回develop時，最終可能會導致衝突。

四處都是，只要有可能就避免這種情況。如果功能B取決於功能A，則可以在功能B上保持關閉狀態，直到功能A正確合併爲develop或其他。