还记得你手头上项目的第一行代码吗？不妨用下面的命令看看它现在的样子，你看到几条线？
git log --all --decorate --oneline --graph
如果你的非常的密集，无论有多少条线，我要恭喜你，这表明你的项目状态良好
看起来不错
但是如果你的非常散碎，commit记录之间涌现大量的空缺，这解释你的commit存在较多的merge，你很可能须要梳理一下版本库了，下图这样的车祸现场一样的，抢救就免了吧，可以直接拉到火葬场。
你已经去世了
现在口试，口试官常常会不苟言笑的问“你有没有什么问题想要问我的？”，一样平常来说这便是个礼貌性提问，不过既然人家给了机会，咱也别摧残浪费蹂躏，对付不知道要问些什么的工友我教大家一个大略的，就用上面的命令看看团队主项目的git树。如果树“看起来不错”的亚子，这便是个值得加入的团队，如果树不幸长成了“你已经去世了”的亚子，这更是一个值得加入的团队，由于你一显技艺的时候到了！
想想看吧，一手搭建团队不可或缺的devops流程，一步成为核心成员，你不牛逼谁牛逼？是不是有些小激动？醒醒吧，起来跟工头学习搬砖了！
年纪轻轻就该多搬砖
题外话：这东西对我有什么用在学习任何东西之前，都该当明确这东西对我有什么用。相信大家都在大学都学习过高数，从泰勒展开到各种中值定理，如果你是数学干系专业的，末了会一起学到斯托克斯方程组，如今公式里的符号早已忘怀，只剩下那个折磨过自己很永劫光的名词还在脑海里挥之不去。工头在学习高数的时候不止一次疑惑过人生，完备想不通这东西除了能让我毕业还有什么用。直到事情过很长一段韶光，有一次要设计一个老虎机算法，哀求随机给玩家发1-100个金币，均匀值为8。我才第一次用上积分方程，完美实现了需求，乐此不疲地玩儿了一个下午，一直想要刷新最高记录，而无论怎么刷，均匀值始终稳定在8旁边，这真是太故意思了。
解出来a、b来写个老虎机函数吧
至于斯托克斯方程组，我也是有时得知游戏里的爆炸和烟雾效果，实在便是用它拟合出来的，可以说方程求解的越精准，你看到的效果就越逼真。在理解了方程物理意义的那一刻，方程里所有的符号看起来都不再抽象，干瘪的公式犹如被注入了灵魂变得生动和有趣起来。由于对数学产生了新的认识，工头又重新自学了一遍高数，探索了每个方程、公式的物理意义，看看它们能办理哪些实际问题，全体过程非常有趣且使人膨胀，乃至让我一度产生了该当可以把小孩儿辅导到大学毕业的错觉（大雾）
辅导作业被气到心梗
牛逼吹完了，我们来看看学习画一颗俊秀的git树有什么用。最直接的浸染是方便追踪历史记录，通过git树你就可以清晰的看到每次发布的内容，如果线上涌现任何问题，通过git树来回溯涌现问题的韶光并剔除涌现问题的代码比直接打补丁的办法高效一些。要知道掩护一颗干净俊秀的git树须要花费很多精力，这从一个侧面也反响出掩护者对待项目的态度和精神面貌。从更长远的层面讲，干净整洁意味着低熵，而统统降落项目中熵的行为都值得夸奖并一定会得到回报。
整洁的秘密 —— rebase多人互助的项目有两个办法可以完成代码的合并，一个是merge，一个是rebase。merge的优点在于简洁高效，易于节制。缺陷也很明显，merge也会显示在git历史中，尤其是多人互助开拓一个分支的时候，merge数量每每会比较多，让人看不清有效的commit，久而久之git树就会变得非常缭乱。工头掐指一算你的项目多数已经已经是车祸现场了，这倒不是由于工头是个神棍，只不过如果你还不知道rebase或者很少用rebase，git树末了就会变成那个样子，而大量利用rebase的项目就像掩护者一直在修剪分支，始终保持了git树的简洁。
一个项目中的merge每每来自两个地方
在本分支拉取他人的代码 git pull 产生的自动merge将分支合并到上游分支，比如从dev合并到master实在这两个地方的merge都可以通过rebase来办理，在本分支拉取他人代码时添加--rebase参数
git pull origin feature-1 --rebase
将分支合并到上游之前
git rebase -i origin master
让我们来用一个小项目来看看merge和rebase对git树的影响。我们须要完成两个功能，分别创建分支1和分支2，同时在分支1上仿照多人协作开拓的过程。
首先创建master和f1、f2两个分支
在f1上以user1提交a
在f1上以user2分别提交b和c，并修正a
在f1上以user1提交新的d之前，我们须要将user2在f1上新增的b、c以及对a的改动合并过来，此时你有两个选择
git pull origin f1git pull origin f1 --rebase前者会产生一次merge，而后者则不会。这里工头要详解一下pull中的merge操作，pull便是一次fetch + merge，一样平常情形下合并是fast-forwad的
一样平常情形下pull操作的合并都是fast-forward
但是也有分外情形，如果你在合并user2的提交之前在f1上产生了新的提交（这在多人协作中很常见，彼此并不知道对方什么时候会提交），或者你手动添加了--no-ff，那么就会产生一个非fast-forward的合并。
我们先在f1上提交了b，此时产生了非fast-forward合并
以是这个时候你用git pull origin f1 --rebase实际上是做了一个git fetch && git rebase -i f1的操作，将本分支的提交rebase到了user2的提交之后。
利用--rebase，可以看到user1的修正rebase到了user2的提交之后
说完了pull，我们再来看看将分支合并到上游的情形。
在f2上以user1提交e和f，并合并到master
此时将f1合并到master之前，我们须要将master上的改动合并到f1，此时也有两个选择
git merge master 直接将master上的改动合并到f1git rebase -i master 以交互形式进行rebase毫无疑问，前者会多产生一次merge，我们来看看终极的效果，你就知道为什么我们要避免merge了
利用merge将master的修正合并到f1
利用rebase将f1 rebase到master的改动之后
末了在master上完成merge的操作，多人协作的项目上进行合并时建议还是利用-no-ff来合并，这样涌现任何问题也可以及时将全体merge干掉完成回滚。
如果上面的图看得不过瘾，工头做了一个rebase操作的视频，碰着问题的时候可以反复不雅观看此视频，比拟rebase和merge --no-ff之后git树的变革。
视频加载中...
搜索rebase操作你会创造很多文章说它是一个“危险操作”，如果不知道自己在做什么最好不要轻易考试测验。所谓的危险，实在也确实存在，紧张是多人协作时，你checkout出来之前的那个分支，比如master已经合并了很多代码，这个时候如果有冲突，每每会办理多次冲突，缘故原由是rebase操作要将分支里的每个commit都和上游比较并变基，这个时候用merge将上游的修端正接合并到本分支也是可以的，一个可以考试测验的方法是用rebase压缩（squash）冲突开始之后的commit，再考试测验rebase到master。
写在末了一个良好的scm流程，是构建高效Devops的根本。工头将不才篇文章中以Devops的视角解读一个精良的git流是如何事情的，以及掩护一颗俊秀的git树和高效Devops之间的关系。
欢迎关注工头，带你玩儿转Devops
玩儿转Devops —— 支配的艺术
