GIT合並和rebase工作流程確認？

Question

我已經閱讀了其他幾個關於合並VS rebase，使用什么以及何時使用的問題，但我仍然對常規GIT用戶有一些問題。 首先，讓我發布我理解為優秀的GIT實踐：

1. 從現有分支A創建新分支B.
2. 在分支B上添加/提交更改
3. 來自分支A的重新更新
4. 將分支B的更改合並到分支A“

從我到目前為止的理解，上面的工作流程在使用分層分支模型時效果最好（即A =主分支，B =實驗分支用於處理新特征）。 簡而言之，最好重新樹下樹，然后合並回主人。 我在想這個是正確的嗎？

現在，如果與其他可能正在提交/合並A（主分支）的開發人員合作，我認為我最好經常重復步驟2和3，以確保我在分支B上的工作不沖突任何其他用戶一直致力於分支A。如果有任何沖突，使用分支2上的rebase將重新應用我的提交並允許我在合並回到分支A之前解決這些沖突。我的理解是否正確？

最后，這是我的主要問題：如果我不與任何其他開發人員合作，並且我在分支B中完成新功能之前我沒有觸及分支A，那么我可以跳過rebase（步驟3），然后合並分支B進入主分支A？ 我想首先做一個rebase仍然沒有壞處，但是如果我知道自從創建分支B之后沒有觸及分支A，那就沒有必要了。我的理解是否正確？

PS。 我想提前感謝你們給我的任何指導！ 我是GIT的新手，在使用GIT之前從未使用過SCM系統。

謝謝你，Jesse Leite http://www.aurorafxstudios.com/

Answer 1

不，過度使用rebase不是一個好主意。 我這樣開始但除了合並和重置之外什么也沒做。 看看我的工作流程 。 它基於nvie的 。

簡而言之，您希望按照您的工作進行組織。 使分支A成為分支B的基礎。 如果A中的某些內容不好，這可能是一件壞事，“撤消”它可能並不容易。

Answer 2

你的理解是合理的。 如果沒有任何東西觸及A，那么你的rebase將是一個無操作。 A不變的好處是你知道不會有沖突！