最近了解到国内某知名论坛 rd 流程中版本管理这块采取的是 fork 模式，造成开发流程复杂度增高。所以想就这个情况，聊一聊个人对 git 中使用最为频繁的 fork 和 branch 两个命令的理解。
fork 和 branch 的目的均是在不影响原有项目（分支）的前提下加入自己的 idea。
但是 fork 本身并不是 git 原生的命令（看到这里，你可能会尝试执行 git fork，但无一例外，你得到的结果应该是 'fork' is not a git command 之类的提示 ），而是 github（以及其他与 github 类似的代码托管工具）为了简化分支权限管理而增加的一个 special branch 命令，或者你可以简单粗暴的认为 git fork = git branch --check-identity 。
当然，如果你想，也可以通过 git hook 来实现对分支权限的管理（以前我也确实这么干过）。
如果你对于有权限的分支还不是很理解的话，我们可以换个思路。branch 的话，分支本身还是和原有分支在同一个 repos 中，我对分支的任何修改，都会立即体现在 repos 的 commit list 中。但是对于 fork 来说，是将 your origin repos（jane repos） clone 到 my origin repos（我们暂时称之为 mark repos），然后在从 mark repose clone 到 my local repos （我们暂时称之为 star repos）我对 start repose 的任何修改，即使 Push 到 mark repos 中，也不会对 jane repose 产生任何影响（包括 commit list）。
回到最初的话题，版本管理中使用 fork 和 branch 本身是没有太大问题的，对于公司项目来说，最好是能够根据自身场景来，个人的建议如下：
- 如果不同模块（最好是系统）之间的耦合（你也可以理解为代码重合度）较低（或者说大多数的交互都是通过 http 、tcp 通讯），可以使用 fork
2、如果是不同子模块（比如 bbs 的发帖，查看帖子）,且开发人数比较少的话，建议使用一个 branch 来做开发即可；如果你非要按照模块来划分 branch，也不是不可以，但是最好能事先规约，不然后期合并的时候会比较麻烦。
不管是 fork 还是 branch ，日常项目开发最好还是遵循以下原则：
-
修改 和 pull 频繁交互进行。
-
修改 和 commit && push 频繁交互进行。
-
尽早规约，多做沟通。
谢谢,等实践时候再体验