从工作到现在都一直使用git作为代码管理工具，总结一下工作中常用的场景和它们相关的命令，还有自己的一些见解！
一、相关平台
以下平台都是使用git作为代码管理工具的，并且各有自己特色，我4种都有使用，都算稳定可靠！
- gitlab
通常自建代码托管，都首选gitlab，搭建公司自己的代码管理平台，能保证数据安全性，稳定性嘛就看公司人咋样了
- 码云
码云是开源中国 Git 代码托管平台，也支持svn，带宽都高，非常放心托管
- coding
coding以前只提供给个人5个免费仓库，被腾讯收购以后也解决了这一痛点
- github
全球最大的开源项目平台，想保存私有仓库是需要收费的，而且还是美元，大家一般就在上面发布开源代码，由于服务器在国外，速度不行
二、一次迭代开发
假设现在需求评审完毕，已经分配了下来需求开发，并且将需求分配到了每个人的手中，然后准备开发，怎么操作git仓库呢？
- 1、拉出迭代分支（基于master）
一般公司有自己的平台的话，通过平台创建迭代就能创建origin的迭代分支了
- 2、拉出自己的开发分支（myDev）
git checkout -b myDev
- 3、在myDev分支上开发，并各种commit
git add .
git commit -m '更新内容'
- 4、push自己分支到origin/myDev
git push origin myDev
- 5、向迭代分支发起pull request请求，请求合并到迭代分支上（经同事code review）
发送一个合并请求，经review后，可合并到迭代分支
- 6、迭代分支上验证功能点，不断完善
测试完功能点，全部通过后推上预发环境，数据量的变化会影响一些功能，然后做出相应的调整。在预发调整完，验证完毕后，就会开始走发布流程，先是灰度（让一部分用户体验，相当于体验服），然后没有问题，在全量发布。
- 7、全量发布
全量发布时，以master分支merge迭代分支，然后以master分支来全量发布
git merge '分支名'
- 8、（可选）回滚
如果这次迭代出现不可预期的问题，并且并非短时间可以解决的问题，那么就只能选择回滚，对于代码上将，就是把这次迭代的
git revert <commit_id>
二、从线上master拉自己的开发分支
我们开发不能本地随便找个分支就开发吧，有的冗余代码在某个分支，上次迭代就没提上去，这次直接以这个分支开发，然后不就提上去了吗？所以直接以master分支为基线创建我们的开发分支为稳当。
- 1、创建我们的开发分支
git checkout -b myDev origin/master
- 2、push到线上
git push origin myDev
- 3、与线上关联
git branch --set-upstream-to=origin/myDev
三、依赖同事某次的提交
我们还不想合并代码，但是我们却依赖同事的某次commit，或者两三次，可以考虑使用 cherry-pick
# 只将感兴趣的 commit 加入当前代码
git cherry-pick commit1
git cherry-pick commit2
四、处理代码冲突的原则
git当同时更改了一份文件时，提交就会发生冲突，需要一个人合并之后二次提交才行。
有时候同事把你的代码干掉了，你真的想打人啊，我想说的是，一起开发项目时，冲突在所难免，但是处理冲突的选择能决定最终的结果。
- 1、能both
肯定全部保留，这样皆大欢喜，看到变更的和自己无关，那样可以保留双方的。
- 2、只能保留一方的
如果只能保留一方，优先保存别人的，自己的再新增一部分都行，把别人的干掉我只能送一句话（不怕神一样的对手）
- 3、双方都需要修改的
基本不存在哈，无非是需要同事一起确定下功能逻辑
五、多功能点且独立的点开发时
我强烈建议每个功能点都拉一个本地分支，然后在需要合并代码时再拉一个分支来整合自己的每个功能点，然后以这个集中的分支来向迭代分支合并代码。这样的好处就是：
- 1、假如开发不完全部的功能点，能发布一部分
- 2、比如需要下掉某些点，你可以在集合的分支上剔除那个功能就行了
总之，掌握分支操作很重要，能将事情很简单的解决
六、主分支迭代之后同步到开发分支
使用git rebase master合并主分支，rebase就是调整基线，以现在分支结果为基线
git rebase master
其他
- github作为最大的开源项目发源地将master主分支换成了main
由于master存在种族歧视之类的，GitHub被迫将master更名为main，以后大家主分支就叫main了
