Hello 大家好:
我目前碰到一個問題，是關於 github 的 squash 的問題
在下的 code
https://github.com/p81061473525/test-commit
我有四個分支 main, main-dev,main-devops,main-devops
main 穩定分支
main-dev 從 main 拉出來的分支，會把一堆測試放上去
main-devops 從 main 拉出來的分支，devops 的分支，devops 在上面開發，開發完成會 PR 進 main-dev , CI/CD 觸發是在 main-dev 上面，demo repo 這隻被砍掉了，可以參考 PR close 的地方
由於 CI/CD 會有問題，所以會來來回回 commit 與 PR
main-devops 最後會有三四個 commmit "TEST 1" "TEST2" TEST3"
最後PR到 main 分支裡面去
為了 main 審核乾淨，
從 devops PR into main 模式選擇 squash and merge，
把 commmit "TEST 1" "TEST2" TEST3" 變成 commit -m "TEST"
並且把 main-devops 砍掉
於是 main 只有兩個 commit
這時再從 main 拉出 main-devops2 去開發 CI/CD 新的功能，
假設 commit "TEST4" PR 進去 main-env 這時候就會出現衝突。
雖然可以解衝突，但我不想每次拉新的分支
main-devops3
main-devops4
main-devops*
一直要解衝突
update 5/25
Sorry, 我一直打錯，因為要保護公司分支名稱，所以腦袋沒轉過來。
四隻分支是main (主要的乾淨的 code) 主要是開發lead管理的main-dev 這個是開發lead 從 main拉出來的分支main-devops 這個是我可以從 main拉出來的分支名稱，合併進main這個分支就會被砍掉。main-devops2 這個是我為了這個問題，特別用2來標示，平常我 CI/CD 合併進去，開新的分支名稱還是main-devops
開發者平常也是從 main 拉 功能分支 main-dev-featureX 把代碼提交進 main-dev
devops 也是從 main 拉 main-devops 去做開發把 CI/CD 提交進main-dev，
跑了沒問題 main-devops PR main。
我一定有 main push -f 的權限，可以要強制推要知會開發 lead，但是每一次強推都要開通知開發 lead 這顯然不是一個好作法。
我只是想不透為什麼開發端的成員可以 squash and merge
，開發端成員操作跟我是一樣的，從 main 拉功能分支出來，提交亂亂的 commit，
發 PR 可以 squash
，而我沒辦法 squash
而我做的 demo 也證實我這樣的操作肯定會有衝突
----。
by sourcetree,#4 是 devops squash 合併的
實際上 main-dev 是不會回到 main 上的，但是會定期砍掉，
所以關於 devops 的不跟開法端 code 有影響。
可是如果我沒有 Squash 就會正常，Squash pr 後就會異常。
但我們開發也是 github 提交給開發 lead，開發lead 也是 squash mr .
阿就我的會出conflict
已邀請的邦友 {{ invite_list.length }}/5
小弟才疏學淺，有請靈魂小畫師上線。
如果跟圖一樣的話，我感覺應該是main的node 2跟main的node 1有衝突，你會需要先在本地將main merge進main-devops，這樣main node 2的部分就可以成功了。
有點出入，我晚點補圖，也晚點測試。
實際上 main-dev 是不會回到 main 上的，但是會定期砍掉，
所以關於 devops 的只有你圖的上半部。
可是如果我沒有 Squash 就會正常，Squash pr 後就會異常。
2 的部分是肯定成功的，出問題的點是你圖 3 的位置
可是如果我沒有 Squash 就會正常，Squash pr 後就會異常。
根據這句，我查的結果如下，因為我在版控時，會強調保留commit 紀錄，因此我平常日不用Squash的
Stack Overflow:Why does git-rebase give me merge conflicts when all I'm doing is squashing commits?
不過既然沒有Squash是正常的，那為何乾脆就不要Squash，直接merger呢?
medium:為什麼我不用 Squash and merge
原因，一個字，醜。
因為 main-devops -> main-dev
常常會有
commit4 "test1"
commit3 "test2"
commit2 "test3"
commit1 "test4"
在 main-devopsmain-devops 回到穩定的 main 提交上面 commit 超醜。
main 當然要美美的該長這樣
commit4 "[devops] - env:prod add test stage"
commit3 "[devops] - PR codereview add assign codereviewr"
commit2 "[devops] - build docker images build"
commit1 "[devops] - PR codereview add static test"
不想長成這樣
commit101 "[devops] - env:prod add deploy stage "
commit5~100 "test"
commit4 "[devops] - env:prod add test stage"
commit3 "[devops] - PR codereview add assign codereviewr"
commit2 "[devops] - build docker images build"
commit1 "[devops] - PR codereview add static test"
commit message其實比起美醜，更重要的是內容完整度，有人根據Angular團隊的規範有篇文章可以參考看看。
都已經使用版控了，其實做好這些文件訊息還是比較重要的。
另外，Stack Overflow的方法有幫助到你嗎?
Git Commit Message 這樣寫會更好，替專案引入規範與範例
謝謝你， Stack Overflow 其實沒有幫助，
他其實是用 rebase 與 cheery pick 的作法。去處理的。
main 分支只是穩定版本，穩定版後面還有要合併的情況的。
rebase 我測試過還是沒有辦法，還是會衝突
cheery pick 算不上是 devops team 常規用法
哪一天換其他的團隊成員維護就會覺得怪怪的。
內容完整度我認為確實是每一個 commmit 要清楚，但把一堆"test"丟進去 commmit 肯定不是合理做法。
這個連結 commit 的開頭與寫法我知道，只是寫法規寫法，還是不知道為甚麼衝突的原因
Git Commit Message 這樣寫會更好，替專案引入規範與範例
目前還沒解決，但有一點曙光
最後，我回去比對了一下開發 team 成員 commit，
我想說我那個 demo 很乾淨都會有衝突。
開發 team 怎麼不會沒衝突。
檢查一番後，應該是開發 team 有人定期把 main-dev 砍掉重新把 main 重拉。
所以它們開發分支 merge 進 main-dev 與 main 才不會衝突。
因為找到突破點，我想應該很快會解決。
前面只提到四個分支(main, main-dev,main-devops,main-devops)，怎麼後來又殺出一個 dev-env ？
這問題要解的話，可以考慮找一個最新的分支(裡面東西最全)，然後 push -f main，確保 main 也是最新的，這樣再拉分支應該就不會有衝突了
寫錯 dev-env -> main-env
會有權限上的問題，
不方便直接 push -f main
main 是 dev 跟 devops 都會合併並進去的，
我能控制的只有從 main 拉 devops 出來的動作
main-dev , main 跟 main-dev 是開發管的。
main-env ?
所以四支分支是 main, main-dev,main-devops,main-env ?
那這樣的話，先不要拉新的分支，等到把現有的 main-devops 都合併回去以後，再拉新的分支，確保新的分支是最新的分支
不過奇怪的是你可以發 PR 到 main，但沒有權限 push -f？
Sorry, 我一直打錯，因為要保護公司分支名稱，所以腦袋沒轉過來。
四隻分支是main (主要的乾淨的 code) 主要是開發lead管理的main-dev 這個是開發lead 從 main拉出來的分支main-devops 這個是我可以從 main拉出來的分支名稱，合併進main這個分支就會被砍掉。main-devops2 這個是我為了這個問題，特別用2來標示，平常我 CI/CD 合併進去，開新的分支名稱還是main-devops
開發者平常也是從 main 拉 功能分支 main-dev-featureX 把代碼提交進 main-dev
devops 也是從main 拉main-devops 去做開發把 CI/CD 提交進main-dev，
跑了沒問題 main-devops PR main。
我一定有 main push -f 的權限，可以要強制推要知會開發 lead，但是每一次強推都要開通知開發 lead 這顯然不是一個好作法。
這樣解釋有比較清楚~~
這樣的話，可以靠慮先不要拉新的分支，等到把現有的 main-devops 都合併回去以後，再拉新的分支
然後不是 push -f 以後，之後每次都要 push -f，只是強制更新目前的 main而已，所以只會做一次，除非你常常把 git 搞壞，要拿其他分支去擋...
然後確認一下，你應該知道 squash 完，一定要 push -f 吧？
不太懂，先不要拉新的分支 是什麼意思，我晚點補圖好了。main-devops 本來就會合併到 main
合併完成之後才會拉新的 main-devops
不知道，從網路的資料來看，也不需要 push -f
https://gitbook.tw/chapters/rewrite-history/merge-multiple-commits-to-one-commit
一般開發者應該都是從 main 這樣的穩定分支拉一條出來做 feature branch 完成後合回 main 再拉一隻 feature branch
繼續開發新功能，沒聽過一定要 push -f
不然的話如果一個公司假設5個後端都需要壓縮 commit
codereviewer 幫忙 squash 的話，不就 squash 一次 push -f 一次嗎
iThome鐵人賽
看影片追技術