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

看板Soft_Job作者 (Hi)時間8年前 (2016/06/18 17:47), 8年前編輯推噓26(27推 1噓 57→)
留言85則, 28人參與, 最新討論串1/1
我想我對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
→
06/18 17:53, , 1F
開feature branch再開發 沒人像你們這樣用的
06/18 17:53, 1F
推
06/18 17:55, , 2F
google: git flow 可以先用這套方式跑
06/18 17:55, 2F
→
06/18 17:55, , 3F
如果是另開branch的話和我的想法類似　並且是每個人各自
06/18 17:55, 3F
→
06/18 17:56, , 4F
開一個自已的develop　branch,請問這是正確解法嗎？
06/18 17:56, 4F
→
06/18 17:57, , 5F
其實也不是我會一直這樣作　是有時候涉入不同的project
06/18 17:57, 5F
→
06/18 17:57, , 6F
時會有人多人同時抓一個remote branch下來,然後出現我
06/18 17:57, 6F
→
06/18 17:58, , 7F
可以先看看git flow, github flow的作法 看你的專案類型
06/18 17:58, 7F
→
06/18 17:58, , 8F
說的狀況　我也不確定那樣是否是不對的　但是有點疑惑　
06/18 17:58, 8F
→
06/18 17:58, , 9F
選適合的 通常公司會有些變型的model 但是基本觀念差不多
06/18 17:58, 9F
→
06/18 17:58, , 10F
不過那個project其實算是很小的東西　所以可能沒那麼嚴
06/18 17:58, 10F
→
06/18 17:59, , 11F
謹　但仍然會讓我疑惑就是了　　
06/18 17:59, 11F
→
06/18 18:08, , 12F
會參考一下git flow,thank you
06/18 18:08, 12F
推
06/18 18:39, , 13F
git pull --rebase
06/18 18:39, 13F
推
06/18 18:51, , 14F
通常會用rebase而不是merge
06/18 18:51, 14F
→
06/18 18:52, , 15F
用interactive的方式
06/18 18:52, 15F
推
06/18 19:03, , 16F
rebase是你要的，還有什麼叫做local pull?
06/18 19:03, 16F
→
06/18 19:04, , 17F
其實就是pull ,用詞不夠精確吧
06/18 19:04, 17F
推
06/18 19:23, , 18F
Gitflow光master develop這兩個去用就很好用了
06/18 19:23, 18F
→
06/18 19:23, , 19F
修改的時候，本地開新的branch去做，合併前rebase
06/18 19:23, 19F
→
06/18 19:24, , 20F
講錯了，合併時用rebase回develop
06/18 19:24, 20F
推
06/18 19:25, , 21F
推樓上的方法
06/18 19:25, 21F
推
06/18 21:14, , 22F
github跟scrum害人不淺。盡信書(github)不如無書(github)
06/18 21:14, 22F
※ 編輯: pttdocc (219.68.252.87), 06/18/2016 21:41:02
→
06/18 21:44, , 23F
使用rebase是正解
06/18 21:44, 23F
→
06/18 22:02, , 24F
先學懂rebase才是重點...要整在同一個stream上
06/18 22:02, 24F
推
06/18 22:13, , 25F
rebase也是錯的,應該是說git,scrum開發流程是錯的,
06/18 22:13, 25F
→
06/18 22:13, , 26F
要commit前的rebase的bug fixed base
06/18 22:13, 26F
→
06/18 22:13, , 27F
跟你在開發的base根本不一樣
06/18 22:13, 27F
→
06/18 22:15, , 28F
所以原po會有這樣的疑問是正確的,一個合格工程師的直覺
06/18 22:15, 28F
推
06/19 00:23, , 29F
scrum流程是錯的？ 你是不是搞錯什麼？
06/19 00:23, 29F
推
06/19 00:26, , 30F
這樣有什麼問題嗎？
06/19 00:26, 30F
推
06/19 00:28, , 31F
或許你解釋一下所謂"照理"的理是什麼
06/19 00:28, 31F
推
06/19 01:40, , 32F
干scrum什麼事？
06/19 01:40, 32F
→
06/19 01:47, , 33F
rebase 後 base 就不同了，看似不直接相關的模組就算沒
06/19 01:47, 33F
→
06/19 01:47, , 34F
有衝突也有可能造成潛在問題
06/19 01:47, 34F
→
06/19 01:48, , 35F
所以 rebase 前後結果可能會有差異，不重新驗證會有風險
06/19 01:48, 35F
推
06/19 02:00, , 36F
用錯誤的方法開發(git,svn branch 或 scrum)
06/19 02:00, 36F
→
06/19 02:00, , 37F
即使重新驗証也是錯的，因為rebase且重新驗証過後的base
06/19 02:00, 37F
→
06/19 02:00, , 38F
跟別人正在開發的code base根本不一樣
06/19 02:00, 38F
推
06/19 02:03, , 39F
git svn 就算了 scrum 又不是版本控制...
06/19 02:03, 39F
推
06/19 02:12, , 40F
原來Scrum跟這個有關係 受教了 呵呵
06/19 02:12, 40F
推
06/19 02:19, , 41F
請跟google學習一下什麼是：scrum、CI CD github
06/19 02:19, 41F
推
06/19 02:25, , 42F
這不是單純git的問題而已嗎？樓上一直丟其他名詞出來可以
06/19 02:25, 42F
→
06/19 02:26, , 43F
解釋一下關聯性嗎？
06/19 02:26, 43F
→
06/19 09:02, , 44F
單純的 git 疑問而已，亂扯 scrum 幹嘛
06/19 09:02, 44F
推
06/19 09:03, , 45F
跟 scrum 有啥直接關聯？
06/19 09:03, 45F
→
06/19 09:58, , 46F
同樣覺得乾scrum啥XDDDDDDDDDDDDD
06/19 09:58, 46F
推
06/19 10:36, , 47F
branch一出去各自都是各自的主幹
06/19 10:36, 47F
推
06/19 10:41, , 48F
A merge成的(D)有push了嗎？
06/19 10:41, 48F
推
06/19 13:49, , 49F
覺得rebase是錯誤的+1
06/19 13:49, 49F
推
06/19 14:06, , 50F
等等 A跟B為什麼在同一個branch上？
06/19 14:06, 50F
推
06/19 14:16, , 51F
這個標題跟文章怎麼會跑出scrum.....
06/19 14:16, 51F
→
06/19 14:29, , 52F
正常, 愈後面 push 的愈倒楣, 可能要解 conflict,
06/19 14:29, 52F
→
06/19 14:31, , 53F
一定要有一個倒楣鬼解 conflict
06/19 14:31, 53F
噓
06/19 14:32, , 54F
Scrum本身就不是操作git的sop，是一個開發產品的框架。
06/19 14:32, 54F
→
06/19 14:32, , 55F
某s要不要把書唸通再來？怎麼講出來的話像pm講的？
06/19 14:32, 55F
推
06/19 15:08, , 56F
github表示躺著也中槍 git != github好嗎...
06/19 15:08, 56F
推
06/19 16:14, , 57F
scrum的CI(Continuous Intergation)
06/19 16:14, 57F
→
06/19 16:15, , 58F
若google後跟版控(git,github,svn,CVS...)的關係都不懂
06/19 16:15, 58F
→
06/19 16:15, , 59F
那只能繼續跟原po一樣抱著疑問入棺材了
06/19 16:15, 59F
→
06/19 16:15, , 60F
煩請再google一下,我不想再打字了
06/19 16:15, 60F
→
06/19 16:15, , 61F
還有我已經講得太多了,level夠的一聽就懂
06/19 16:15, 61F
→
06/19 16:15, , 62F
不相信的就繼續當義和團信奉敏捷開發吧
06/19 16:15, 62F
→
06/19 16:27, , 63F
整個flow就是錯的
06/19 16:27, 63F
→
06/19 18:00, , 64F
我看某s不是不想再講太多，是沒什麼料可以講吧？先把scr
06/19 18:00, 64F
→
06/19 18:00, , 65F
um裏規定的git做法的部分跟我說。Jeff Sutherland跟Ken
06/19 18:00, 65F
→
06/19 18:00, , 66F
Schwaber什麼時候教授scrum中git的操作流程？google一
06/19 18:00, 66F
→
06/19 18:00, , 67F
下自己理解scrum規定git做法，level真的太低了。
06/19 18:00, 67F
→
06/19 18:02, , 68F
啊，google完就以為自己懂了。真的是跟那些二流pm一樣
06/19 18:02, 68F
→
06/19 18:02, , 69F
欸！
06/19 18:02, 69F
→
06/19 18:03, , 70F
不知道的版友還真的被你誤導學歪了。
06/19 18:03, 70F
→
06/19 18:24, , 71F
我出社會這麼久了還是不懂 看來我level太低了...
06/19 18:24, 71F
→
06/19 18:26, , 72F
XDDDDDDDD讓我想到了20元打8折要賣多少的那篇文章
06/19 18:26, 72F
→
06/19 18:45, , 73F
雖然開發流程跟 git branch 策略有關，但推文提到 scrum
06/19 18:45, 73F
→
06/19 18:45, , 74F
也扯太遠了
06/19 18:45, 74F
→
06/19 18:55, , 75F
感謝大家的建議　我也覺得講到scrum,CI去太離題了 如果對
06/19 18:55, 75F
→
06/19 18:55, , 76F
scrum有看法也許另開一篇詳述看法更好　這篇只是問git
06/19 18:55, 76F
→
06/19 18:56, , 77F
另外我發現我最後一張圖有點畫錯 C應從B分支出 但是並不
06/19 18:56, 77F
→
06/19 18:57, , 78F
會混肴我原本的問題"pull remote回來的local branch 變
06/19 18:57, 78F
→
06/19 18:58, , 79F
成merge commit的first parent,好像分支搶主流　有點怪"
06/19 18:58, 79F
→
06/19 18:59, , 80F
其實應該前面二張圖就能表達疑問了 而rebase也許是個作法
06/19 18:59, 80F
推
06/20 21:46, , 81F
rebase也要小心，push上remote的commit千萬不能rebase
06/20 21:46, 81F
推
06/22 03:43, , 82F
我的做法是開local branch開發，commit之後，先切回main
06/22 03:43, 82F
→
06/22 03:43, , 83F
branch pull最新的code,回到local branch 用 rebase 把m
06/22 03:43, 83F
→
06/22 03:43, , 84F
ain branch拉進來，解conflict,回到main branch,merge lo
06/22 03:43, 84F
→
06/22 03:43, , 85F
cal branch,然後 push,就不會有你說的線繞來繞去的問題
06/22 03:43, 85F
‣ 更多 pttdocc 的文章
文章代碼(AID): #1NPHZC77 (Soft_Job)