[請益] 請問這樣的git用法對不對

[pttdocc (Hi)]

我想我對git應該還有些地方不夠了解　　所以才會有這樣的疑問　　

我的疑問大致是　假如有A和B二個人　都同時把某個branch (假設branch_1)　從某
個相同的commit A 開始　抓到local 來修改　

remote ---------(A)
A      ---------(A)
B      ---------(A)


假如B先作了一個修改(B)　commit 和push 回branch_1 (B),
fast forward,這沒問題,B接著又作了一些修改(C),而A自從抓回(A)後也作了修改(D)
remote ---------(A)-----------(B)
A      ---------(A)--------(D)
B      ---------(A)-----------(B)-----(C)


A改完(D)後要commit時conflict,這種時候很多人是pull remote 回來,然後再commit ,
如下　

remote ---------(A)--------(D)----(merge1)
                   \----------(B)---/

A      ---------(A)--------(D)----(merge1)
                   \----------(B)---/

B      ---------(A)-----------(B)-----(C)


這時感覺就有點奇怪了,因為照裡說(B)那條線應該算是主幹,可是A local pull,時就會把
主幹搶過來,好像河流支流變主幹一樣　

雖然說以拓撲上來說,(B)和(D)哪個是主幹,有人會說只是github之類工具圖形呈現的方式,
但似乎不是這樣,因為在log 裡　(merge1)　會有二個parent commit,而順序上(D)那條
會變主要的parent commit



而B的(C)要commit 前也必須先pull merge remote回來,再push,就變成(C)那條又變
主幹,把(D)搶走,如下　　

remote ---------(A)--------------------(C)--------(merge2)
                 \ \----------(B)----------\         /
　　　　　　　　　\---------(D)---------(merge1)----/

A      ---------(A)--------(D)----(merge1)
                   \----------(B)---/

B      ---------(A)--------------------(C)--------(merge2)
                 \ \----------(B)----------\         /
　　　　　　　　　\---------(D)---------(merge1)----/

這裡誰是主幹誰是支流,應該不只是tool呈現方式而已
(因為有人會說,我把(B)那條拉直看不就(B)從頭到尾都是主幹了？）
因為merge commit裡,順序第一的parent commit算是主幹,git 的概念應該是這樣沒錯吧

因此很多visualize的tool也會照我上面畫,整個線就會被拉來拉去的

####################################################

我想問的是,這種push 前先pull merge,造成主線拉來拉去的狀況,是否是個問題,

如果是問題的話,有人會說,不然你push前不先pull,那remote有修改你要怎麼作？
其實我也不太確定,也許另拉一個開發用的branch是個方法？　　　



不知道我上面的提問大家能否看得懂,盡量畫的和說明的易懂了　
謝謝　　



--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.68.252.87
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1466243276.A.1C7.html
※ 編輯: pttdocc (219.68.252.87), 06/18/2016 17:49:59
→ banjmin: 開feature branch再開發 沒人像你們這樣用的
推 alog: google: git flow 可以先用這套方式跑
→ pttdocc: 如果是另開branch的話和我的想法類似　並且是每個人各自
→ pttdocc: 開一個自已的develop　branch,請問這是正確解法嗎？
→ pttdocc: 其實也不是我會一直這樣作　是有時候涉入不同的project
→ pttdocc: 時會有人多人同時抓一個remote branch下來,然後出現我
→ banjmin: 可以先看看git flow, github flow的作法 看你的專案類型
→ pttdocc: 說的狀況　我也不確定那樣是否是不對的　但是有點疑惑　
→ banjmin: 選適合的 通常公司會有些變型的model 但是基本觀念差不多
→ pttdocc: 不過那個project其實算是很小的東西　所以可能沒那麼嚴
→ pttdocc: 謹　但仍然會讓我疑惑就是了　　
→ pttdocc: 會參考一下git flow,thank you
推 mrsquid: git pull --rebase
推 yyc1217: 通常會用rebase而不是merge
→ yyc1217: 用interactive的方式
推 popcorny: rebase是你要的，還有什麼叫做local pull?
→ pttdocc: 其實就是pull ,用詞不夠精確吧
推 abc0922001: Gitflow光master develop這兩個去用就很好用了
→ abc0922001: 修改的時候，本地開新的branch去做，合併前rebase
→ abc0922001: 講錯了，合併時用rebase回develop
推 pptsodog: 推樓上的方法
推 sunsamy: github跟scrum害人不淺。盡信書(github)不如無書(github)
※ 編輯: pttdocc (219.68.252.87), 06/18/2016 21:41:02
→ rsshppp: 使用rebase是正解
→ alongalone: 先學懂rebase才是重點...要整在同一個stream上
推 sunsamy: rebase也是錯的,應該是說git,scrum開發流程是錯的,
→ sunsamy: 要commit前的rebase的bug fixed base
→ sunsamy: 跟你在開發的base根本不一樣
→ sunsamy: 所以原po會有這樣的疑問是正確的,一個合格工程師的直覺
推 EQQD: scrum流程是錯的？ 你是不是搞錯什麼？
推 CaptainH: 這樣有什麼問題嗎？
推 CaptainH: 或許你解釋一下所謂"照理"的理是什麼
推 Masakiad: 干scrum什麼事？
→ Vitaceae: rebase 後 base 就不同了，看似不直接相關的模組就算沒
→ Vitaceae: 有衝突也有可能造成潛在問題
→ Vitaceae: 所以 rebase 前後結果可能會有差異，不重新驗證會有風險
推 sunsamy: 用錯誤的方法開發(git,svn branch 或 scrum)
→ sunsamy: 即使重新驗証也是錯的，因為rebase且重新驗証過後的base
→ sunsamy: 跟別人正在開發的code base根本不一樣
推 jlhc: git svn 就算了 scrum 又不是版本控制...
推 EQQD: 原來Scrum跟這個有關係 受教了  呵呵
推 sunsamy: 請跟google學習一下什麼是：scrum、CI CD github
推 mrsquid: 這不是單純git的問題而已嗎？樓上一直丟其他名詞出來可以
→ mrsquid: 解釋一下關聯性嗎？
→ kewang: 單純的 git 疑問而已，亂扯 scrum 幹嘛
推 timmy5519: 跟 scrum 有啥直接關聯？
→ dreamnook: 同樣覺得乾scrum啥XDDDDDDDDDDDDD
推 comesuck: branch一出去各自都是各自的主幹
推 comesuck: A merge成的(D)有push了嗎？
推 Darkautism: 覺得rebase是錯誤的+1
推 SHANGOYANYI: 等等 A跟B為什麼在同一個branch上？
推 MysterySW: 這個標題跟文章怎麼會跑出scrum.....
→ descent: 正常, 愈後面 push 的愈倒楣, 可能要解 conflict,
→ descent: 一定要有一個倒楣鬼解 conflict
噓 Masakiad: Scrum本身就不是操作git的sop，是一個開發產品的框架。
→ Masakiad: 某s要不要把書唸通再來？怎麼講出來的話像pm講的？
推 chargo: github表示躺著也中槍 git != github好嗎...
推 sunsamy: scrum的CI(Continuous Intergation)
→ sunsamy: 若google後跟版控(git,github,svn,CVS...)的關係都不懂
→ sunsamy: 那只能繼續跟原po一樣抱著疑問入棺材了
→ sunsamy: 煩請再google一下,我不想再打字了
→ sunsamy: 還有我已經講得太多了,level夠的一聽就懂
→ sunsamy: 不相信的就繼續當義和團信奉敏捷開發吧
→ dlikeayu: 整個flow就是錯的
→ Masakiad: 我看某s不是不想再講太多，是沒什麼料可以講吧？先把scr
→ Masakiad: um裏規定的git做法的部分跟我說。Jeff Sutherland跟Ken
→ Masakiad:  Schwaber什麼時候教授scrum中git的操作流程？google一
→ Masakiad: 下自己理解scrum規定git做法，level真的太低了。
→ Masakiad: 啊，google完就以為自己懂了。真的是跟那些二流pm一樣
→ Masakiad: 欸！
→ Masakiad: 不知道的版友還真的被你誤導學歪了。
→ yyc1217: 我出社會這麼久了還是不懂 看來我level太低了...
→ honochung: XDDDDDDDD讓我想到了20元打8折要賣多少的那篇文章
→ kewang: 雖然開發流程跟 git branch 策略有關，但推文提到 scrum
→ kewang: 也扯太遠了
→ pttdocc: 感謝大家的建議　我也覺得講到scrum,CI去太離題了 如果對
→ pttdocc: scrum有看法也許另開一篇詳述看法更好　這篇只是問git
→ pttdocc: 另外我發現我最後一張圖有點畫錯 C應從B分支出 但是並不
→ pttdocc: 會混肴我原本的問題"pull remote回來的local branch 變
→ pttdocc: 成merge commit的first parent,好像分支搶主流　有點怪"
→ pttdocc: 其實應該前面二張圖就能表達疑問了 而rebase也許是個作法
推 abc0922001: rebase也要小心，push上remote的commit千萬不能rebase
推 shietsd: 我的做法是開local branch開發，commit之後，先切回main
→ shietsd:  branch pull最新的code,回到local branch 用 rebase 把m
→ shietsd: ain branch拉進來，解conflict,回到main branch,merge lo
→ shietsd: cal branch,然後 push,就不會有你說的線繞來繞去的問題