背景：假設從 master 1.0 版本新建分支重構程式碼，新分支稱為 v2。 在重構過程中，master 1.0 不斷有新的修改或 bug 修復合併。等到 v2 開發完成時，兩個分支之間差異太多，衝突也很多。
這樣的場景下，如何處理才能比較好的發布 master 2.0？ 實務中，當重構程式碼時，如何操作才能比較好的避免大量衝突的出現？
你好，如何處理合併時的衝出，沒有什麼簡單方式，可能就得相應業務人員逐條處理了。 就重構的方式有些異議，重構過程中master有bug處理、功能發布。 v2為什麼不及時合併呢？ 若master 1每次正式發布，master 2都能及時合併，衝突了量就會減少了吧！
我們也遇到類似問題.比如有一個穩定版本stable,下面有個目錄是fs然後以一個開發分支develop,下面有個目錄是fsv2
新版本都是在develop上開發,並且fs目錄也已經廢棄,相關fs的程式碼都在fsv2目錄下修改了.
這個時候出現一個需要立刻做hotfix的問題,hotfix是在stable的fs上做的,那develop的fsv2目錄怎麼才能把這個修改merge進去呢,我們是在每次hotfix的時候主動對develop分支進行backport ,把新的patch在新分支上實現一次.
對於hotfix是這樣,對於大的feature的開發,相對而言stable一般是不需要了,如果兩邊都需要做,那最好就是放在一個公共的目錄下,做成較為通用的模組之後進行merge .
這是我自己的經驗,可能比較落後,還請大家指教.
一般而言，如果重構的部分在master 1.0沒有被修改當然不會出現問題。
如果重構的部分還有新的修改，那麼進行這兩項任務的人員必須溝通好，否則在merge時肯定出現問題。
不過通常情況下，不需要一邊重構，又一邊修改同一部分程式碼吧。真要這麼做，兩項任務也不需要完全同步進行，可以重構一天，修改一天，重複合併分支。
你好，如何處理合併時的衝出，沒有什麼簡單方式，可能就得相應業務人員逐條處理了。
就重構的方式有些異議，重構過程中master有bug處理、功能發布。 v2為什麼不及時合併呢？
若master 1每次正式發布，master 2都能及時合併，衝突了量就會減少了吧！
我們也遇到類似問題.
比如有一個穩定版本stable,下面有個目錄是fs
然後以一個開發分支develop,下面有個目錄是fsv2
新版本都是在develop上開發,並且fs目錄也已經廢棄,相關fs的程式碼都在fsv2目錄下修改了.
這個時候出現一個需要立刻做hotfix的問題,hotfix是在stable的fs上做的,那develop的fsv2目錄怎麼才能把這個修改merge進去呢,我們是在每次hotfix的時候主動對develop分支進行backport ,把新的patch在新分支上實現一次.
對於hotfix是這樣,對於大的feature的開發,相對而言stable一般是不需要了,如果兩邊都需要做,那最好就是放在一個公共的目錄下,做成較為通用的模組之後進行merge .
這是我自己的經驗,可能比較落後,還請大家指教.
一般而言，如果重構的部分在master 1.0沒有被修改當然不會出現問題。
如果重構的部分還有新的修改，那麼進行這兩項任務的人員必須溝通好，否則在merge時肯定出現問題。
不過通常情況下，不需要一邊重構，又一邊修改同一部分程式碼吧。真要這麼做，兩項任務也不需要完全同步進行，可以重構一天，修改一天，重複合併分支。