【摆烂git操作指南】怎么提交个代码这么麻烦？你会不会用Git啊
此文git技术含量极低，git使用老手可以直接划过了。
仅以此文来纪念那个不熟悉git又不敢问人因此一个人默默瑟瑟发抖的菜鸟时光。
1.git是什么，它和github的关系。
这就不用多说了，不知道这个的去问下你的老师，他可能会给你一个大比兜。
2.开发之前的准备工作
2.1 把代码先拉到本地（git clone ...）
来到新公司，leader让你把代码拉下来，然后环境什么的装一下，先熟悉一下代码什么的。
然后你就吭哧吭哧把工具什么的下好了。然后就到最后一步了，拉项目代码。
给你一个仓库地址，你进去以后，找到仓库的HTTP或者SSH的地址，输入git clone xxxxx.。这两种克隆项目的方式都可以把代码成功拉下来，其他区别不用知道，只要记住一点的就是https方式每次提交代码时需要输入用户名密码，ssh方式则不用。这里两者具体细节不谈。（ssh方式如何生成ssh key百度一下就行）
tips: 如果拉不下来代码，也要注意一下是否项目管理员是否给了权限。
2.2 git配置(git config ...)
这一步在安装好git时就可以做了，无非就是两个命令
git config --global user.name "your name" // 设置全局用户名
git config --global user.email "your email" // 设置邮箱
不设置这个东西代码是无法提交的。
3.什么是暂存区，什么是本地库，什么是远程库？
你在日常使用git add ...，git commit ...，git push ...这三条铁打的命令时，其实就是把你的代码换到了三个地方存放：暂存区、本地仓库和远程仓库。
暂存区相当于一个后悔备用区。
本地库可以直接理解成你的电脑。
远程库当然就是github、gitlab、gitee等等代码托管平台了。
它们之间的关系可以大致理解为这样：
一个功能写完了，需要先从暂存区提交到本地库，再推到远程库。
3.1 暂存区与git add 命令
暂存区是什么，可以理解成一个后悔区。使用git add ...以后，可以把某些或全部文件保存到暂存区中，然后从暂存区中拿出来也是非常方便的。但是一旦commit以后你后悔了，就只能把整个commit提交的文件全部返回了。
对于新手来说还是挺恐惧取消commit这个操作的（没错，以前我就是）。
git add ...命令就是用于把编辑好的代码提交到暂存区，怎么用的话搜一下就可以了，很简单的。
如果使用vscode或者sourcetree的同学。以vscode为例。vscode自带的git工具可以很清晰的看到你有哪些文件当前在暂存区，有哪些已经保存的文件需要提交到暂存区，然后点点点就可以直接实现暂存区文件的提交与取消暂存功能了：
3.2 本地仓库与git commit命令
要想把暂存区的代码提交到本地仓库，就是git commit ...命令了，一旦使用此条命令，你的提交历史里就会出现这条记录，使用git log命令就可以看到所有git commit ...历史提交记录了。或者直接在git仓库的History里也可以看到。
你的leader如果看到一段代码写的跟坨shit一样，就可以看到原来是你写的，然后。。。：
3.3 远程仓库与git push命令
好了，功能写完了，要提交到git仓库了。此时就可以使用git push ...命令把本地仓库的代码推送到远程仓库了。
3.3.1 推送之前记得拉同事的代码（git pull）
此时你潇洒的输入git push命令，再潇洒的按下回车，令人期待的0% ~ 100%的进度条并没有出现，而是[reject] falied balabala等等红黄报错。。。
但是不要急，先看怎么说的：
翻译过来就是：拒绝。。。巴拉巴拉。。。'git pull ...'。。。巴拉巴拉。
很明显，看到了熟悉的git pull，它就是在说，请先拉你同事的代码，有其他的崽种也提交了代码，你要先把他的代码拉下来，你两的代码合起来再推到远程仓库。
这说明什么？说明你的同事下次拉代码的时候也要先拉你的代码才能推到远程仓库。就这样一来一回，你提交我来拉，我提交你也要拉，功能不就一点一点做完了吗。
3.3.2 拉完代码冲突了怎么搞
正常你开发你的功能，我开发我的功能，不会出现冲突，直接一招git pull 把当前分支的代码全部更新到本地，看着一条条和谐的绿色的+和红色的-出现在终端上。然后按下git push 0% - 100%跑完你如释重负，脸上露出的满意的笑容。
大部分情况下git pull + git push两招就能完成代码拉取和提交工作。但是有时候你git pull拉完，出现的并不全是是和谐的红色 -和绿色 +，然后你的项目还跑不起来了。然后你的功能相关文件名还变红了，点进去发现：MD，谁改我代码了！看了下commit记录，发现是你的崽种同事。
你问他为什么改你代码，他轻蔑一笑，说我觉得你这写的不优雅，我有代码洁癖，我看不下去。
好，你说不优雅就不优雅吧，你是大哥，我是菜鸡，你说啥就是啥。现在就是解决冲突了。你会在编辑器中看到如下：
冲突的上方会看到四个按钮，意思分别是：采用自己代码、采用崽种同事的代码、两个都要、先比较一下看看。这时候你就需要和你崽种同事唇枪舌剑一番决定用谁的代码了。
所有的冲突会在git pull 命令的返回信息中提示出来，凡是有CONFLICT (content): Merge conflict in ...的都是提示这个文件内有冲突了。
不用担心冲突文件找不到了，毕竟项目都跑 不起来了，你还怕找不到哪里出问题了吗
4.分支
分支就很容易理解了，它就是一个从主分支复制出来的包含源分支代码的但是又和源分支暂时没有关系的"代码库"，然后新分支又可以有自己的分支，一级一级的就像树杈子一样，然后把你自己的分支上的代码合到主分支上。主分支再合到其他的主分支上。结构就像这样。
4.1 从主分支切换一个自己用来开发功能的分支（git checkout -b ..）
当你的leader说：嘿，张三。这有个"角色管理"的新功能，就给你来做吧，记得从dev切个新分支开发哦。
你说：没问题，保证完成任务！
然后你就可以打开vscode，先用git pull拉取了dev的最新分支代码，然后再按下git checkout -b dev_张三_开发角色管理。一按回车出现如下文字：
可以，新分支创建成功了。在这里我可以为所欲为了，嘿嘿嘿。
4.2 开发完的功能怎么合并到主分支（git merge ...）
好了新功能开发完毕了，leader找你要代码了，这时候就需要把你自己分支的代码合并到dev主分支了。
现在你回到了dev分支，由于dev分支其他的同事也在开发功能且你有段时间没有碰dev分支了，你本地的代码肯定和远程仓库的代码不是一致的，所以需要先把远程仓库最新的dev分支的代码先pull下来。拉下来以后有冲突就解决冲突，需要更新node包就更新node包。
然后就可以把你自己开发功能的分支合并到dev分支了。在控制台输入了git merge dev_张三_开发角色管理，看着控制台一行一行新增/删除的文件，还没有冲突，你的笑容再一次挂上了嘴角。
和git pull 一样合并后的代码一样可能有冲突，解决它就好啦。
最后，看着开发过自己shit like代码的分支，表示自己再也不想看到它了，然后就把它删了(git branch -d dev_张三_开发角色管理)。嗯，很不错。
4.3 你代码太垃圾了，我要review。你提merge request/pull request我来审核吧（提交合并请求）
还记得第一次听到merge request，整个人都有点慌。woc，这是什么？我要怎么操作？怎么办？下午功能就要测试了。代码要怎么合？整个人后背都有点发烫，但是脸皮薄的我却不敢问，怕别人说我这怎么都不会。
我真的好菜。
经过上一次让你自己push dev分支的代码，你的leader发现你的代码写的一言难尽，不敢再让你自己动dev分支的代码了。于是他对你说，你下次功能写好了提个merge request，我来给你合代码，再给你review一样。
你心想：劳资代码写的这么好，居然还不相信我？
这时候的操作是把你自己从dev切出来的那个分支先推送到了远程分支(git push set...)。但是，你自己的分支要先把dev的代码合过来，如果有什么冲突要先在本地解决了再push到远程自己的分支。说起来有一丢丢绕，但是总体就是：
- 在合并时自己的分支的代码要包含当前主分支的最新代码。
- 冲突要放在自己本地解决。
此时的命令就不是在主分支执行git merge ...了，而是先在dev分支把远程dev分支代码先拉下来，然后回到自己的分支，再执行git merge dev，合并结束以后，你自己的分支就包含当前dev远程分支的最新代码了。接着git push把自己的本地分支推送到自己的远程分支。
上面这些做完了，自己本地git的操作就结束了。接来下，打开浏览器，进入你的git仓库，进入当前项目页面。
在正中间会有一个Pull Request/Merge Request字段。没错点击它
注意： github、gitee的字段是Pull Request，gitlab用的是Merge Request。这两个的区别可以不用深究，不过它们达到的目的都是一样的。
进入以后就会看到一个按钮，上面有着new Merge(Pull) Request字段，点击后就会进入合并页面：
gitee，gitlab，github，界面都不太一致，不过，总体操作都是差不多的。都是先选择从哪个分支合并到哪个分支。然后再填写一些描述信息以及审核人等等信息最后再提交就行了。
恭喜你，你已经成功提交了一个Merge/Pull Request。然后你就可以打开钉钉：老大，我提了merge，你过目一下呢。
4.4 源代码我都不想让你碰了，你把仓库fork下来再提merge吧。
我在听到fork时的状态和我听到merge的状态基本一样。woc，fork是什么？要怎么操作？同样的后背一阵发烫。想想真的是又菜又脸皮薄呀。
上次你提了merge以后，老大眯着眼看完你的代码。
这写的是啥？没眼看。然后他又提要求了。我不想你的分支在仓库里出现了。你把项目fork下来，再提merge吧。
5.小结
这篇文章并没有很高深的git的知识，只是记录一下一个只会用git add . 、 git commit -m 巴拉巴拉 、 git push三条铁打的git命令的菜鸟到现在的对git的了解及使用。
作为一个普通开发者，不乱操作分支的话，上面这些基本知识和命令已经足够日常开发使用了。如果出现了一些不知道怎么操作的意外情况，问一下老大或者搜索一下git如何...也基本能解决问题。
不过如果项目比较庞大，分支比较庞杂，就需要更多的git指令来提高我们代码分支管理的效率了。这方面有很多大佬的文章，多多学习吧。