共计 1485 个字符，预计需要花费 4 分钟才能阅读完成。
背景
什么是分支? 简单地说, 分支就是两个相对独立的时间线, 正常情况下, 独立的时间线永远不会有交集, 彼此不知道对方的存在, 只有特定情况下, 两条时间线才会相遇, 因为相遇, 所以相知, 因为相知, 所以改变!
正如分支对于科幻电影来说是一个很好的卖点, 关于分支的话题完全可以开启新的题材, 对于这点相信不少科幻迷都深有体会, 不必赘述.
回归正题, 分支对于版本控制系统又意味着什么呢? 实际工作中, 我们大多作为一个团队一起合作开发项目, 如果是独立开发者, 只有一个人的话, 其实用不到分支的概念, 甚至远程仓库也用不到. 所以下述情况针对的都是团队开发情况.
作为团队中的一员不论是项目领导还是项目成员, 都需要了解并掌握分支的一般概念和常用操作. 如果你刚好是实际开发的程序猿, 上级领导分派一个新功能, 预期两个星期内才能完成, 其他同事也是如此, 每个人都有自己的任务. 接收任务就要开始干活, 第一天工作开了一个头, 还留下一大堆的 TODO 标记, 此时你照例运行 git add ,git commit 等命令, 学会上节的 git push origin master 你知道了本地仓库和远程仓库的概念, 你想将你的工作成果分享给其他人就要推送到远程仓库, 这样其他人才能可见, 等一等, 别急!
首先明确的是, 这个完整功能至少需要 2 个星期才能基本完成啊, 你现在刚刚起了个头还没完成呢! 你要是真的推送到远程仓库了, 那其他人是不是有理由认为你这部分功能已完成? 那你可能会反驳说, 我可以在工作群吼一声, 说这个功能还没完成, 大家别着急使用哈! 这样确实可以, 很长一段时间内其他人必须无视你的代码, 只有等你的功能基本可用时, 等你再吼一声, 别人才会去使用你的代码. 粗略一看, 好像并没有什么问题?!
实际上这种情况是存在很大风险的, 因为未完成未经过测试的代码可能会产生大量意外 bug, 严重的话, 甚至影响整个系统, 到时候由于你的未完成代码导致别人项目都无法运行, 那别人还怎么工作, 这个责任是谁负责?
所以, 为了不给其他人造成麻烦, 最好不要把未完成工作直接暴露到别人面前, 那长时间提交又可能会造成丢失更改的风险, 此时此景, 平行时间线应用而生!
从接手新功能的时间点开始, 创建一条新的时间线, 于是新功能的开发完全在新的时间线上进行, 至于其他人是否开启新的时间线那就不是我们能控制得了, 我们能做到的就是不给其他人制造麻烦, 如果其他人给我们制造麻烦的话, 那我们就去上级领导那告他一状, 哈哈!
等功能开发差不多时, 你再想办法切换到原来的时间线上并将开发时间线的更改顺便都带过来, 这样一来, 别人虽然看不到你的开发时间线, 但是看到了你离开的这段时间原来做了这么多的更改啊!
现在用 git 的专业术语再解释一遍上述场景:
接手新功能的时刻开始, 创建一个开发分支 (既可以是本地分支也可以是远程分支), 以后新功能的开发全部在开发分支上完成, 处于开发分支上你可以照常运行 git add ,git commit 等命令, 不用担心丢失更改. 等工作一段时间后, 终于完成了新功能, 是时候让新功能展示给其他同事了. 此时再切换到原来的主干分支, 在主干分支上合并开发分支, 现在主干分支上已经有新功能了, 这样一来, 其他同事突然发现你已经偷偷地完成了新功能的开发!
不仅 git 有分支概念, 其他版本控制系统比如 svn 也有分支概念, 基本概念和常用操作类似, 只不过 git 更强大, 创建分支, 切换分支, 合并分支等功能十分强大, 效率太高!(svn 创建分支, 切换分支等操作简直慢到可以喝一杯茶了, 分支管理都快成摆设了!)
建议
开发新功能时尽量创建自己的分支, 不要给其他人造成麻烦
分配任务时要求项目成员创建各自分支, 等时机成熟时再合并到主干分支
