Git经典套路
Git代码管理是技术负责人的必修课。
简单，清晰的Git管理流程可以避免小弟们日后无数的妖怪问题
这次代码到底应该提到哪个分支啊啊啊33333
我c...我的代码怎么没了？谁干的!!
老板，冲突太多了，代码合不上去啊
哎呀代码提错了，怎么回滚啊（几百个文件）
......
我们今天就聊聊如何老练地管理代码分支（最佳实践）。
既然我们是入沟系列而不是入坑系列，Git基础知识就不讲了，如果还不太知道Git是干嘛的请大家自行百度。
稳定分支
稳定分支是指长期维护的，永不下线的分支，这些分支随时都可能用来部署各种各样的环境。
非要举个例子的话就比如你手里泡枸杞的保温杯是稳定分支，给装修师傅用的一次性杯子是临时分支。
不要做太多稳定分支，不然你的小弟们会搞不清楚代码到底提到哪儿。
稳定分支多少算多呢？
如果来了一个新的小弟，你两分钟内没办法跟他讲清楚这整件事情，那么你的稳定分支就太多了。
稳定分支一般而言是根据你当前有多少套研发环境决定的。
常用研发环境有哪些？
dev环境
开发环境。
小弟们干活的环境，代码（没测过的，以及自称测过的）会部署到这个环境，给测试大兄弟们秀一千零一种翻车姿势。
sit环境
集成测试环境。
如果你的小弟分为了多个团队，你可能需要一个集成测试环境，来验证dev环境测试通过的，各个团队的代码可以友好相处，所有的流程可以安安稳稳从头跑到尾。
stage环境
预发布环境。
这理论上是一个仿生产环境（一般也只是理论上）。这套环境可以让你演练一组功能的上线流程，免得上线磕磕绊绊。测试大兄弟们也会在这个环境做倒数第二遍功能测试。
最佳实践
为每一个有意义的研发环境分配一个稳定分支。
综上，你应该有这么几个稳定分支：
- master分支，用来部署stage以及任何生产环境。
- dev分支，用来部署dev环境。
- sit分支，用来部署sit环境。注意这个分支是可选的，你可以压根儿不要sit环境。
临时分支
临时分支是指用过即弃的分支，他甚至不需要出现在远程代码库中，只存在于开发大兄弟的电脑上。
什么时候需要拉取临时分支
线上代码hotfix
这个时候需要从master分支复制一个临时的hotfix-bugxxxx的分支出来。
所有修改在 hotfix-bugxxxx 完成后，将 hotfix-bugxxxx 合并到master，并部署stage环境，给测试大兄弟验证。
stage验证通过后，将master发布到生产，完成hotfix修复。之后hotfix-bugxxxx临时分支弃用。
新的需要独立上线的特性
同样从master分支复制一个临时的feature-xxxx 分支出来。
新特性在feature-xxxx开发完成后，将feature-xxxx合并到dev分支，并部署dev环境，开始dev测试（修bug修bug修bug.....）。
dev测试通过后将feature-xxxx分支合并到sit分支，并部署sit环境测试（修bug修bug修bug.....）。
sit测试通过后将feature-xxxx分支合并到master分支，并部署stage环境测试（修bug修bug修bug.....）。
最后把master发到生产环境，新特性上线。feature-xxxx临时分支弃用。
最佳实践
每当遇到需要独立发布的特性或者bug修复的时候，单独从master复制一个临时分支，在临时分支进行修改。
注意，总是从master复制分支，因为其他分支中包含了各种不能上线的半成品功能。
Git奇技淫巧
Cherry Pick
Cherry Pick是指将A分支指定的几个commit 合并到 B分支。老外起名字还是非常形象的。
一般而言（就是说实际情况并不是这样的），master分支的特性是最少的，因此按道理总是可以随时merge回sit分支或者dev分支。同理sit分支总是可以随时merge到dev分支。
但是由于可能有成百上千个大兄弟分别在有限的几个稳定分支合并代码，时间长了这种自上而下的分支合并可能会面临非常多的代码冲突。
所以当我们从master复制了一个featurexxx分支，想要合并到dev分支，给测试大兄弟测试的时候，可能没那么容易。
Intelij提供了非常方便的cherry pick 功能！可以非常方便地把feature分支上，指定的几个commit合并到dev分支，冲突的概率大大减小！
定期重置dev分支
dev分支虽说是个稳定分支，但是你会发现时间长了会充斥着很多废代码（功能做了一半发现做不下去的，需求取消的，对应功能产品经理离职的等等）。
因此，当每个迭代开始的时候，技术Leader可以强制将master覆盖到dev分支。
git reset --hard xxxx
如果发现提交了错误的合并，可以通过这个命令返回到一个指定hash的状态。
结合 git push xx:xx -f命令，可以回滚远端仓库的分支hash。
这是大招，请慎用。
多人共用临时分支
当你的特性需要依赖其他人的前置开发时，可以在远端代码库维护一个共用的临时分支，大家共同在一个feature分支上开发。
Git翻车集锦
请永远不要做以下的动作。
- 把dev或sit分支，merge到本地的feature临时分支，或者本地的hotfix临时分支。这会让你的本地分支多出各种别人的代码，导致你的分支无法单独上线。
- 当遇到代码冲突的时候，直接删掉冲突的代码。这会导致别人的代码丢失，要去询问冲突代码的开发兄弟，为什么他也会改这里。
- 分别将相同的代码修改，单独贴到master，sit，或dev分支。这会导致大量的冲突。请永远别这么干。代码只修改一次，然后将修改内容merge到目标分支，不要在每个分支都修改一次。
