开源项目二开如何让 git 不分叉。

@msg7086 我有一个 Apache 项目 pmc，不知道比你的小多少

@YouLMAO 其实我不太明白你提 Apache PMC 和你提出的团队里用 Rebase 是对团队不负责任有什么关系。
在我看来，Good practice 应该是对团队负责任的行为，只不过是因为需要妥协一些现实中无法解决的情况（例如队友太菜）而不得不采取变通的措施。
从你前面的观点，即「用 Rebase 」→「对团队不负责任」这个论点来看，我觉得有两种可能。
1. 你觉得 Rebase 让版本历史保持清晰不属于 Good practice ；
2. 你觉得 Good practice 是对团队不负责任的行为。
你想说的是其中的哪个呢？

我司姑且不算很小，但是我不代表我司发言，所以就不报名号了。
但是我司要求每个 MR 都使用 Squash 方式合并，这样既不会有 Merge 也不会有 Rebase 。
说白了只是为了省事，省得培训每个员工罢了。
我自己的个人项目是不会去用这么 low standard 的做法的。

PR/MR 没 merge 之前随便 rebase，有什么好纠结的。如果开发分支也多人协作那就定好了标准，做 rebase 完就即时同步给小伙伴就可以了。你 rebase，他也 rebase 没有太多问题。稍微配合下 cherry-pick 让提交历史好看一些也是不错的。
合并之后再改历史是大忌。

@YouLMAO 这不就典型的菜怪工具不好用么？ squash+rebase 逻辑很清晰的，git blame 一下整个历史清清楚楚

squash+rebase 之后拿工具就可以方便的检测出整个系统的依赖关系，通过把 interface 写在一个独立的 repo 里面，可以很方便的实现多个 pipeline 同时自动回滚，如果是多个 branch merge 过来的话，回滚到哪个 branch 的哪里去？

rebase 唯一解答，只要在本地端還沒推送上去的內容，沒有什麼理由不能 rebase 。

@tlerbao 你这样用，本地 Master 还是 Origin Master，还是 Dev 分支内容都是一锅粥。现在你看到只是自己一个人的几次提交 Log，等你在项目有多个人的时候，提交了几个月再去看你的 Log 吧。

我使用的原则：我的 Master （本地或者 Origin 上）尽可能与 Upstream Master 致。每次创建分支前，都是必须要同步操作，保持与上游一致。

而且我的经验是是大部分情况下，我的开发分支不需要中途 Rebase，绝大多数情况下，在 PR Merge 的选择 rebase 是可以合并进 Upstream Master 的（冲突的时候，直接在 Github Web 界面上修改冲突，合并即可）。Git 不仅仅是配置管理一部分，分支与任务颗粒度大小匹配，这与软件开发管理经验和实实在在软件架构的设计也很大关系，尽可能是一个分支对应的任务快速完成（ 4 小时到一天内最好，超过了一天，就应该考虑这个 Issue 是不是包含太多的内容），而且有清晰依赖关系（不要依赖没完成的任务）。

这个 Flow 不是我发明的，Github 最初版本的 Flow 包含这个步骤的。只是现在看到的 Github Flow 版本官方教程，省略了 Fork，简化了很多。而 Fork 在 Github 最初的理念正是体现了 Social Coding 。

我一般是本地 rebase 一遍 rebase -i, 然后 Squash, 最后再推上去 主干永远是一条线

@msg7086 很难不资瓷

git stash
git fetch
git stash pop
git push