問題是這樣的
專案在開發可能會因為開發某 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）
各位有什麼建議嗎？

像github一樣 fork 然後pull

git flow? master 不上commit?

一樓的意思是，相當於在多一層（forked repo）把 feautrebranch 作的事情，放在forked repo 作，最後PR回去嗎？master上commit可能是其他feature completed, merged in

feature/boo_v1 feature/boo_v2

樓上的意思是在 branch 內分版號蓋資料夾嗎？

feature2 從 feature1 分支出來，兩個相互 merge，最後再由 feature1 merge 回 master

這樣作法讓我有點混淆，這樣feature2其實不是feature但是卻有了branch 還且還是在feature1上，而branch原因不明在圖上有會看到feature有從master來的線, 這樣很亂還是說這些動作是在 local 作，所以feature2最終只會變成feature1的空降commit(相當於處理完merge master的diff)是這樣的意思嗎？這樣的話假設是以squash方式rebase(from f2 to f1)最終feature1回到master有沒有辦法處理這個commit?已經作過的commit會不會在重新算一次？如果不是squash的話那勢必與master之間的線就變成蜘蛛網了

參考一下 https://github.com/google/guava/pullsfork 像branch 但實際上完全是獨立的 repo在自己的repo中改完後，到原project 提出pull request大家玩法不盡相同，我是沒有再用branch了

merge master into feature沒有什麼不好啊..如果你的feature branch控制得好的話.(local到remote都有rebase.. 那最後graph也只有master到feature的一條線而已.. 不會太亂啦當然通常feature也不會拉太長時間兩週差不多可以merge/rebase回master了..就不會有需要master到feature這段了

多人開發同一個 branch 本來就是會互相 merge只在意 merge graph 好不好看你就不用做事了

感覺用 forked_repo + PR 比較容易達成這其實是實行 git flow 所注意到的缺點git flow 上所建議的 branch 有其意義, 他可以在 rollback更能清楚的帶出 source 可以修改的方向或是要切換版本間開發有更大的彈性但「事實上」用到這些「彈性」的時機很少，甚至可以說是假議題也無妨,實務上當然是怎麼merge都可以, 甚至anti-flow直接使用master也是一種玩法!我所想要探知的是以git flow 玩feature branch 怎麼解這些問題

要merge graph一條線要幹嘛？用到SVN嗎大家都開個新branch，統一由一個人合到master類似這種流程 https://goo.gl/gX5sPd

我原本也不在意，但在回頭看到1920解析度無法裝下git log--graph 的 branch line, 切確的發現branch merge已失去意義(確認我們的開發人數+branch並沒有這麼大的規模^^")這種嚴謹 merge team 似乎是個作法，但就要看規模了

我的建議是: 1)研究 git 的 pretty 設定 2) 裝tig...如果 tig 下去圖還是很難讀，那感覺開發規模也不小了若功能branch只有一個人用，時常rb到master上然後forcepush 也是解法，不過這最好搭配對 master 的保護機制，像是 gitlab 的 protected branch切 branch 除了考古方便以外，一個人同時做兩三個功能時也相對不容易搞混自己做到哪裡，可以整個環境抽換掉或是像是一邊開發新功能一邊修舊bug之類的....另外是多人合作時，送pull request就是該code review了...這時候進 master 的意義就變成"code 有被審過"

感謝建議! 我會來試試看