月月冬瓜
幫人解git conflict還教他rebase用了兩小時,希望他有搞懂
拜託工程師把git的常用功能了解一下好嗎
Incel ㄈㄓ
這個也太…
月月冬瓜
Incel ㄈㄓ
如果有學會就好了
月月冬瓜
Incel ㄈㄓ : 希望他能回去優化一下他們公司的工作流程
月月冬瓜
plusku: 我覺得這應該要取決於怎麼用XD
自己local端rebase一下應該是禮貌,不要一直merge來merge去的線圖很醜
月月冬瓜
plusku: 除非你只有自己在寫不然怎麼可能維持漂亮XD
月月冬瓜
plusku: 你最後還不是要合回master?
月月冬瓜
A 和 B branch同時從master出來,A先merge進master,你B也是不rebase就合回master嗎?
月月冬瓜
plusku: 那線圖就⋯很醜啊XD
A和B如果不小心有conflict你也是在merge的那包解嗎。
月月冬瓜
plusku: 我覺得不行www 不過你們可以接受就好
月月冬瓜
plusku: 先說的確有些限制是不靠merge不行的,我不清楚你們的分支結構也不敢斷言你們的做法不正確。
僅就剛剛我舉的例子,我要了解B到底改了什麼,除了看B的commit,還要看merge conflict解了什麼。如果rebase的話你只要看B的commit就好,因此我當然會覺得先rebase是較佳的做法。
月月冬瓜
至於feature寫完的push問題,你應該要有一個自己的force-push branch,不能跟別人共用,完全作為備份工具,這樣一來當然可以頻繁rebase。
理論上來說進code前rebase就好,但是我強迫症比較嚴重,會一直想跟最新的master對齊,所以就會頻繁rebase,這樣不知道清楚否。
月月冬瓜
plusku:我是覺得要在merge一次解掉所有conflict,本身就是很容易出錯的事啦XD 不單單只是醜的問題而已
rebase可以讓你在出現conflict的時候分次分次解,scope變小也比較好知道哪邊出錯。
月月冬瓜
plusku: 那這樣就是線圖很醜的問題了。我不太確定用git blame看的時候會不會也有影響,我是蠻常用這個功能的。看某行程式進code時的commit message來判斷這行有沒有特殊用意。要是只能看到「merge branch blablabla」我應該會蠻幹的吧。
月月冬瓜
plusku: fix bug / Improve code / hello world
Incel ㄈㄓ
initial commit
apmk|正太好可愛
A, B 各merge master還好。
問題是A開發中途需要master的新東西,如果不用rebase而是merge from master to A,圖真的醜爆…
月月冬瓜
apmk|正太好可愛 : 忘記這個case,這個真的不能接受XDDD
載入新的回覆