作者Samuel (I've got it!)
看板Soft_Job
標題[請益] git 操作問題
時間Wed Mar 9 14:55:14 2016
問題是這樣的
專案在開發可能會因為開發某 feature
從 master 切 branch 出來
如果需要 master 上面的 update
如果是自己的話就還好 可以自己在 local git rebase
但是如果多人開發同一個 feature
會交互的 commit code 到 remote 上
在需要 update master code 的時候
這樣的話就不能作 rebase
通常的作法會是 cherry-pick
噁心一點的話就會直接把 master merge into feature
會造成 git merge graph 相當的可怕
問題說到這邊
也許有人會說
「為什麼要從 master merge into feature？，這樣不對啊」
「可能是 feature 切的不夠細」
「可能是 commit 顆粒掌握不對」
...
會有一些類似這種 operation 上面的認知的問題
說這麼多是想請問各位大大
以 git remote rebase(誤) 作為糾結的起點
各位有什麼解法嗎？！
或是有什麼 best practice 可以躲過這些問題？
我想要做到的就是「不影響他人的」remote rebase 作法 XD
（當然 remote 是無法 rebase 我知道 QQ）
各位有什麼建議嗎？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.170.73
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1457506517.A.0AA.html
1F：→ abola921: 像github一樣 fork 然後pull 03/09 15:06
2F：推 spjay1: git flow? master 不上commit? 03/09 15:23
3F：→ Samuel: 一樓的意思是，相當於在多一層（forked repo）把 feautre 03/09 15:34
4F：→ Samuel: branch 作的事情，放在forked repo 作，最後PR回去嗎？ 03/09 15:34
5F：→ Samuel: master上commit可能是其他feature completed, merged in 03/09 15:36
6F：→ JingJing00: feature/boo_v1 feature/boo_v2 03/09 15:40
7F：→ Samuel: 樓上的意思是在 branch 內分版號蓋資料夾嗎？ 03/09 15:59
8F：推 dojay: feature2 從 feature1 分支出來，兩個相 03/09 16:20
9F：→ dojay: 互 merge，最後再由 feature1 merge 回 m 03/09 16:20
10F：→ dojay: aster 03/09 16:20
11F：→ Samuel: 這樣作法讓我有點混淆，這樣feature2其實不是feature但是 03/09 16:36
12F：→ Samuel: 卻有了branch 還且還是在feature1上，而branch原因不明 03/09 16:36
13F：→ Samuel: 在圖上有會看到feature有從master來的線, 這樣很亂 03/09 16:37
14F：→ Samuel: 還是說這些動作是在 local 作，所以feature2最終只會變成 03/09 16:38
15F：→ Samuel: feature1的空降commit(相當於處理完merge master的diff) 03/09 16:39
16F：→ Samuel: 是這樣的意思嗎？ 03/09 16:39
17F：→ Samuel: 這樣的話假設是以squash方式rebase(from f2 to f1) 03/09 16:40
18F：→ Samuel: 最終feature1回到master有沒有辦法處理這個commit? 03/09 16:41
19F：→ Samuel: 已經作過的commit會不會在重新算一次？ 03/09 16:41
20F：→ Samuel: 如果不是squash的話那勢必與master之間的線就變成蜘蛛網了 03/09 16:42
22F：→ abola921: fork 像branch 但實際上完全是獨立的 repo 03/09 18:09
23F：→ abola921: 在自己的repo中改完後，到原project 提出pull request 03/09 18:10
24F：→ abola921: 大家玩法不盡相同，我是沒有再用branch了 03/09 18:14
25F：推 popcorny: merge master into feature沒有什麼不好啊.. 03/09 18:32
26F：→ popcorny: 如果你的feature branch控制得好的話.(local到remote 03/09 18:32
27F：→ popcorny: 都有rebase.. 那最後graph也只有master到feature的一 03/09 18:33
28F：→ popcorny: 條線而已.. 不會太亂啦 03/09 18:33
29F：→ popcorny: 當然通常feature也不會拉太長時間 03/09 18:33
30F：→ popcorny: 兩週差不多可以merge/rebase回master了.. 03/09 18:34
31F：→ popcorny: 就不會有需要master到feature這段了 03/09 18:34
32F：→ legnaleurc: 多人開發同一個 branch 本來就是會互相 merge 03/09 20:55
33F：→ legnaleurc: 只在意 merge graph 好不好看你就不用做事了 03/09 20:55
34F：→ Samuel: 感覺用 forked_repo + PR 比較容易達成 03/09 21:48
35F：→ Samuel: 這其實是實行 git flow 所注意到的缺點 03/09 21:49
36F：→ Samuel: git flow 上所建議的 branch 有其意義, 他可以在 rollback 03/09 21:49
37F：→ Samuel: 更能清楚的帶出 source 可以修改的方向 03/09 21:50
38F：→ Samuel: 或是要切換版本間開發有更大的彈性 03/09 21:50
39F：→ Samuel: 但「事實上」用到這些「彈性」的時機很少，甚至可以說是假 03/09 21:51
40F：→ Samuel: 議題也無妨,實務上當然是怎麼merge都可以, 甚至anti-flow 03/09 21:52
41F：→ Samuel: 直接使用master也是一種玩法! 03/09 21:53
42F：→ Samuel: 我所想要探知的是以git flow 玩feature branch 怎麼解這些 03/09 21:55
43F：→ Samuel: 問題 03/09 21:55
44F：推 abc0922001: 要merge graph一條線要幹嘛？用到SVN嗎 03/09 22:23
45F：推 abc0922001: 大家都開個新branch，統一由一個人合到master 03/09 22:30
47F：→ Samuel: 我原本也不在意，但在回頭看到1920解析度無法裝下git log 03/09 23:02
48F：→ Samuel: --graph 的 branch line, 切確的發現branch merge已失去意 03/09 23:03
49F：→ Samuel: 義 03/09 23:03
50F：→ Samuel: (確認我們的開發人數+branch並沒有這麼大的規模^^") 03/09 23:06
51F：→ Samuel: 這種嚴謹 merge team 似乎是個作法，但就要看規模了 03/09 23:08
52F：推 GALINE: 我的建議是: 1)研究 git 的 pretty 設定 2) 裝tig... 03/09 23:55
53F：→ GALINE: 如果 tig 下去圖還是很難讀，那感覺開發規模也不小了 03/09 23:56
54F：→ GALINE: 若功能branch只有一個人用，時常rb到master上然後force 03/09 23:58
55F：→ GALINE: push 也是解法，不過這最好搭配對 master 的保護機制，像 03/09 23:58
56F：→ GALINE: 是 gitlab 的 protected branch 03/09 23:59
57F：→ GALINE: 切 branch 除了考古方便以外，一個人同時做兩三個功能時 03/10 00:01
58F：→ GALINE: 也相對不容易搞混自己做到哪裡，可以整個環境抽換掉 03/10 00:01
59F：→ GALINE: 或是像是一邊開發新功能一邊修舊bug之類的.... 03/10 00:03
60F：推 GALINE: 另外是多人合作時，送pull request就是該code review了... 03/10 00:05
61F：→ GALINE: 這時候進 master 的意義就變成"code 有被審過" 03/10 00:06
62F：→ Samuel: 感謝建議! 我會來試試看 03/18 21:32