[請益] git 操作問題

[Samuel (I've got it!)]

問題是這樣的
專案在開發可能會因為開發某 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
→ abola921: 像github一樣  fork 然後pull
推 spjay1: git flow? master 不上commit?
→ Samuel: 一樓的意思是，相當於在多一層（forked repo）把 feautre
→ Samuel: branch 作的事情，放在forked repo 作，最後PR回去嗎？
→ Samuel: master上commit可能是其他feature completed, merged in
→ JingJing00: feature/boo_v1   feature/boo_v2
→ Samuel: 樓上的意思是在 branch 內分版號蓋資料夾嗎？
推 dojay: feature2 從 feature1 分支出來，兩個相
→ dojay: 互 merge，最後再由 feature1 merge 回 m
→ dojay: aster
→ Samuel: 這樣作法讓我有點混淆，這樣feature2其實不是feature但是
→ Samuel: 卻有了branch 還且還是在feature1上，而branch原因不明
→ Samuel: 在圖上有會看到feature有從master來的線, 這樣很亂
→ Samuel: 還是說這些動作是在 local 作，所以feature2最終只會變成
→ Samuel: feature1的空降commit(相當於處理完merge master的diff)
→ Samuel: 是這樣的意思嗎？
→ Samuel: 這樣的話假設是以squash方式rebase(from f2 to f1)
→ Samuel: 最終feature1回到master有沒有辦法處理這個commit?
→ Samuel: 已經作過的commit會不會在重新算一次？
→ Samuel: 如果不是squash的話那勢必與master之間的線就變成蜘蛛網了
推 abola921: 參考一下 https://github.com/google/guava/pulls
→ abola921: fork 像branch 但實際上完全是獨立的 repo
→ abola921: 在自己的repo中改完後，到原project 提出pull request
→ abola921: 大家玩法不盡相同，我是沒有再用branch了
推 popcorny: merge master into feature沒有什麼不好啊..
→ popcorny: 如果你的feature branch控制得好的話.(local到remote
→ popcorny: 都有rebase.. 那最後graph也只有master到feature的一
→ popcorny: 條線而已.. 不會太亂啦
→ popcorny: 當然通常feature也不會拉太長時間
→ popcorny: 兩週差不多可以merge/rebase回master了..
→ popcorny: 就不會有需要master到feature這段了
→ legnaleurc: 多人開發同一個 branch 本來就是會互相 merge
→ legnaleurc: 只在意 merge graph 好不好看你就不用做事了
→ Samuel: 感覺用 forked_repo + PR 比較容易達成
→ Samuel: 這其實是實行 git flow 所注意到的缺點
→ Samuel: git flow 上所建議的 branch 有其意義, 他可以在 rollback
→ Samuel: 更能清楚的帶出 source 可以修改的方向
→ Samuel: 或是要切換版本間開發有更大的彈性
→ Samuel: 但「事實上」用到這些「彈性」的時機很少，甚至可以說是假
→ Samuel: 議題也無妨,實務上當然是怎麼merge都可以, 甚至anti-flow
→ Samuel: 直接使用master也是一種玩法!
→ Samuel: 我所想要探知的是以git flow 玩feature branch 怎麼解這些
→ Samuel: 問題
推 abc0922001: 要merge graph一條線要幹嘛？用到SVN嗎
推 abc0922001: 大家都開個新branch，統一由一個人合到master
推 abc0922001: 類似這種流程 https://goo.gl/gX5sPd
→ Samuel: 我原本也不在意，但在回頭看到1920解析度無法裝下git log
→ Samuel: --graph 的 branch line, 切確的發現branch merge已失去意
→ Samuel: 義
→ Samuel: (確認我們的開發人數+branch並沒有這麼大的規模^^")
→ Samuel: 這種嚴謹 merge team 似乎是個作法，但就要看規模了
推 GALINE: 我的建議是: 1)研究 git 的 pretty 設定 2) 裝tig...
→ GALINE: 如果 tig 下去圖還是很難讀，那感覺開發規模也不小了
→ GALINE: 若功能branch只有一個人用，時常rb到master上然後force
→ GALINE: push 也是解法，不過這最好搭配對 master 的保護機制，像
→ GALINE: 是 gitlab 的 protected branch
→ GALINE: 切 branch 除了考古方便以外，一個人同時做兩三個功能時
→ GALINE: 也相對不容易搞混自己做到哪裡，可以整個環境抽換掉
→ GALINE: 或是像是一邊開發新功能一邊修舊bug之類的....
推 GALINE: 另外是多人合作時，送pull request就是該code review了...
→ GALINE: 這時候進 master 的意義就變成"code 有被審過"
→ Samuel: 感謝建議! 我會來試試看