[請益] git 操作問題

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