是否安全地壓縮來自其他分支的提交

開發流程中feature分公司並有多次提交該分支完成，但它們之間有一些融合了master分支，所以日誌功能分支，例如像：

它是安全的壁球這一切都提交到一個feature commit 1？

在將feature分支合併到master時，是否會遇到任何問題？

2017-07-22 marknorkin

你會在什麼時候壓扁？在合併之前？ –

@TadijaBagarić不，在這次合併之後發生了 – marknorkin

將所有這些提交壓縮到一個特性提交1中是否安全？

不，這不是安全的這樣做

是否有合併功能分支到主站時，我會遇到什麼問題？

據我所知問題是，在那種情況下，你改變主分支的歷史，基本上爲每個人制動。

當你從你的第一個到最後一個的所有提交的feature分支擠壓時，你將壓縮所有主提交以及這兩個提交，甚至主提交改變了不同的文件，那麼你做了。

所以你壓扁的提交會有很多改變的文件，你根本沒有改變，當合並回主分支，即使這些文件的內容沒有改變，但提交哈希被改變，所以在這個回購協議中與你一起工作的人們以後會遇到各種各樣的衝突。

2018-01-01 09:57:00 marknorkin

對master分支上的任何文件所做的任何更改都會導致合併衝突（甚至更糟，無用的靜默覆蓋），因此任何其他人將工作交給master會給您帶來問題，從而使協作變得更加困難。

在另一方面，如果你的feature分支歷史看起來像，因爲您在功能開發過程中需要從master變化，爲什麼不rebase你feature分支上的master頂部，當你需要更新？

基本上，它會做的就是讓你feature看起來就像在合併之前從master分支出來。功能開發過程中

所以，如果你使用合併獲得master更新：

但是如果你使用變基獲得master更新：

所以，當你想合併你的feature回到master，合併將基本上是一個快速向前合併，將您的功能提交到master分支之上。

當然，在合併更合適的情況下，就像您想保留歷史記錄一樣，但這取決於您和您的工作流程。

一些更多的資源，這將更好地解釋合併/變基差：

2017-07-22 08:24:28

當您完成您的特性分支工作，你需要將它合併到主分支。在執行此操作時，如果特性分支和主分支在相同位置包含更改，則可能會遇到合併衝突。由於合併是在本地存儲庫中進行的，因此它很安全，您可以花時間確保所做的所有更改都是正確的。但是，當你推動你的改變並且他們將會被團隊使用時，那麼你做的任何錯誤都會升級。

出於這個目的，在許多情況下建議將主體合併到要素分支中，修復您的要素分支中可能的合併衝突，然後將其合併回主體。我知道這涉及到一個額外的民主步驟，但這是值得的，因爲您可以選擇在沒有任何風險的情況下推動合併，如果有人可以回答您的未解決問題或測試人員嘗試解決問題，那麼您在一個更安全的情況下。

推動掌握並不總是超級風險。風險級別取決於推送到主服務器和推送代碼之間的距離。如果推送給主人的任何內容立即生效，那麼這是非常危險的，而如果主人是分期，那麼風險就會降低，但是，我認爲解決功能分支中的任何可能的合併問題更有禮貌，一切都很好，然後將它合併回主。

如果主控自上次合併到功能後沒有更改，則可以將功能分支合併到主控中。

從理論上講，合併每個單獨提交更安全，但前提是這些提交經過良好測試，但實際上沒有人會這樣做，沒有一個非常具體的原因，就像其他人做出的某些更改可能與您不兼容變化。但是，這隻有當頭部合併因某些原因而失敗時才需要，並且您需要確定不兼容性來自何處。

2017-07-22 08:52:35

回答