问题是这样的
专案在开发可能会因为开发某 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 有被审过"

感谢建议! 我会来试试看