我有好幾個分支，其中兩個是dev跟master，dev用來開發，master當產品版本，有bug時會直接從master開hotfix修改，然後併到dev跟併回master
問題來了，一開始dev跟master進度一樣，之後我在master開了好幾個修改的hotfix分支，改完後會先併到dev測試，沒問題才會併回master，有可能好幾個hotfix修改測試完後才一次併回master
這時候我在已經併入先前hotfix的master又開了一個新的hotfix，修改後想併到dev，這時卻發現dev被比較出沒有先前已改完的那幾個hotfix，而導致除了本次的hotfix外還多出先前幾個hotfix在本次合併清單上，也就是hotfix比的是當初最原始跟master一樣進度的dev，但目前的dev跟matser已各自併入先前的hotfix，但是不知道為什麼在合併時還是以最初的dev當作比較對象
請問有什麼機制導致git會以舊的dev來當作比較對象嗎?base? 或是master跟dev兩個分支需要sync一下? 感謝!!
已邀請的邦友 {{ invite_list.length }}/5
感覺 master 有點多餘，長久下來 master 與 develop 的 code base 會有差異。
如果是我會只留一條 develop，當確定當前 commit 是穩定的就打上 tag。
不知道其他人有沒有更好的做法 XD
單人作業的情況下，會覺得有點多餘。
但如果多人作業的話。有時 master 與 develop 還不一定足夠使用。
之前曾經有過一個專案是區分 master 、test 與 develop 。
其原因是因為他們其實還有分正式站及測試站。兩個站都算上線的版本。
不過有版本號的還是只有 master 就是了。
test只是做為當測試站用的版本。
當然，那時我也直接問過說，為何不把 develop 當測試站就好。
後來在實際開發也了解到為何要這樣做。
因為測試站雖美其名是測試。但實際上它並非是拿來DEBUG使用。
而是用來功能測試使用試驗使用。並不是給工程師用的。是給客戶用的。
其實不是個人的，是公司開發，此外還有SIT UAT分支都有各自進度
這個問題其實我早期在使用git的時候也困擾過。
後來我用的方式是如下的流程
hotfix 一律都是從 dev 去生出的。
但 hotfix 可以合併 dev 也可以直接合併到 master
當然了，我都會跟工程師說好。
要直接合併到 master 的 hotfix。一律要先合併 dev 上。
而當開發完成後，dev 一定要合併回master。(因為其實不用太過擔心重覆合併的問題，畢竟 dev 內一定會存在已合併的 hotfix。)
這是我們後來做的規範。其原因也是因為。有些 hotfix 有急迫性。可能無法等其它 hotfix 作好。
所以得先合併到 master 。
你可以參考我上面的做法看看。
iThome鐵人賽
看影片追技術