1 絮叨

最近因为工作有点忙，加上自己个人生活的一些琐事，突然感觉写文章太难了，不过还是慢慢坚持下来，即使更新频率变慢了。最近的主题还是那个初衷，记录下自己日常开发工作的一些想法。

2 前言Git

在日常的开发工作中，免不了会使用git进行代码管理，熟练使用git会使我们有更多的时间专注于代码编写，加快整体开发效率。然而对我而言，git只是工具，一些常规操作已经足够了，有空有兴趣才会去深入研究它。不熟悉git也不要紧，学学就好，快的话随便看几个命令后自己再实践一下就可以应付日常开发了。

3 常用Git命令

我日常开发有用idea去操作git，当然有些场景也会在idea的Terminal面板去手打命令，当你熟悉了之后，简直是舒服地飞起，会感觉到看似杂乱无章的各个分支里的代码，在你几个命令操作下管理得井然有序。

3.1 克隆项目 git clone

从远程库拉项目到idea： VCS->Checkout from Version Control->Git，贴上URL后点Clone，idea就会帮我们执行git clone命令。

当然，也可以先git clone
https://gitee.com/xxx/Test.git到本地后，在把项目导入idea中

3.2 查看分支 git branch

查看当前项目有哪些分支

3.3 检出代码 git checkout

拉取远程分支代码

git checkout -b dev(本地分支名称) origin/dev(远程分支名称)

3.4 创建分支 git checkout -b

有时你想自己创建一条分支可执行 git checkout -b dev(分支名)

相当于2条命令

git branch dev

git checkout dev

切记，一定要在最新master分支上创建新分支

3.5 拉取/提交/推送代码 git pull/git commit/git push

这几个操作真的是最基本了，相信在所有命令中，熟悉这个的人占极大多数，这里我一般都是借助idea操作的。

如果是多人在同一分支开发的话，一般在push之前要先pull最新代码，但谁要能保证你即使pull后在到push这一瞬间，有没有人提交代码呢？

若别人有提交代码，idea会在你push时提示你要不要merge，若没有冲突会自动合并，此时git日志里会有这么一行记录 Merge remote-tracking branch 'origin/dev' into dev git的日志记录也不会是一条完整直线了。若有冲突，需要手动解决。
若你先pull，没冲突当然最好，有冲突你会pull失败，提示本地修改会被覆盖。这时可以git stash 暂存修改。暂存成功后 git pull拉取代码。 git unstash将暂存的代码更新到当前分支上。

如果此时有冲突，可手动解决，idea也提供良好的可视化图形，解决冲突变得容易许多。

左边本地代码、右边远程代码、中间合并成功之后的代码

3.6 撤销操作

还没commit就想放弃修改，直接鼠标右键点击文件Revert就好。
commit了之后还没push，想撤回commint前操作。 git reset --hard HEAD~ --hard直接还原到上一版本，不保留修改(慎用) git reset --soft HEAD~ --soft还原到上一版本，保留commit前的修改(常用) git reset --mixed HEAD~ --mixed 与soft不同的是，还原到git add前没暂存的文件图形化 GIt->Repository->Reset HEAD...

HEAD~上一版本

一般都后悔操作上一步，想回退多步直接指定版本号吧 git reset --hard HEAD commit_id

push之后想回退。依然可以用上述操作，只不过在下一次push之后，会拿回退前的版本跟当前修改合并，有冲突要解决。

3.7 合并代码 git merge

这里我一般都是图形化操作，将远程代码合并到自己当前的分支上。

merge dev(分支名) into current

4 多人开发合作模式

所谓的开发合作模式，简单来说就是git的分支管理。

每个公司因为业务量不同、服务器数量不同，都有自己的管理规范。

简单点的可能只有主干master、开发分支dev。

复杂点的多了功能分支feature、bug修改分支fixbug，甚至还有测试分支test、预发布分支pre-release。

当然，这些不同场景的叫法和命名都是自己定义的，但你的项目再简单，最好不要简化到只有master和dev分支。

我曾入职一家公司，看到里面的项目只有master和dev，就直接跟当时的开发说你们这样干，不会遇到某某问题吗？没想到一语中的，所以后面才规范了分支管理规范。

那会有什么问题？

master是线上稳定的代码分支，一般不能直接在上面修改，这时产品来了2个或以上需求，因进度不同不能同时上线，这时你们共用一个dev，那岂不是把别人未测试过的代码给上了？你可能会说我们公司需求不多，上线一个功能才开发下一功能，那自己私下想写些demo测试优化，还不是要在dev上改？
2个功能需求想一起测试、一起上线，那我都在dev开发？最好还是分开，各自建自己的分支开发，避免其他同事在解决冲突时因不熟悉git把你的代码给干掉了。后面想一起上线时再一起合并即可。

目前自己在用的管理模式，master+多个feature分支，仅此而已：

需求下来，在master上建个功能分支，命名f+时间+功能名，如：f_20200521_coupon(暂且定义A)。
本地开发、服务器上测试都直接部署功能分支的代码。
测试通过即将上线时，checkout本地的master，git pull拉最新代码。
再切换回自己的功能分支A，并merge matser into current，手动解冲突。
如果想连同他人的分支(暂且定义B)一起上线，最好先叫你的伙伴先合master代码，然后重复3、4步，checkout B、切换A、merge B。
在gitlab等私服申请请求合并，merge A into matser，这时绝对不会有冲突产生。
合并到master后删除自己的功能分支。
服务器上部署master上线。

为什么有第3步？其实是为了第4、第6步服务的，得先保证你本地的matser是线上最新的，经过第4步之后去到第6步，因为master是最新且在第4步已解决冲突，到了第6步就绝对不会有冲突。

为什么不直接在第3步后就 merge A into current（master）？为了安全，master一般不能在本地直接操作，是一个受保护的分支。

为什么在第4步merge matser into A后还要在第6步merge A into matser，绕来绕去，在逗我吗？上面已经回答了，master分支一般是有权限（受保护）的，merge A into matser不能在本地操作，只能在gitlab（git私服）上操作，但gitlab上又不能手动解决冲突，所以我们要先在本地merge matser into A并手动解决冲突，再到第6步就可以完美合并。