从个人的编码历程总结一些经验。如有收获，还请关注——猩猩伸手.jpg
Git-Flow
在多人协作开发的时候，有一个良好的Git工作流程是会极大提高效率。
当然，如果只是个人开发，那在主分支上修改也不是不可以。
个人常用的工作流是：master-dev-feature
这个工作流是最基础的。如果想要复杂一些，可以加一个预发布分支作为给业务、测试人员的验收，又或者是专门弄一个hotfix分支作为线上版本的bug，从而紧急加速PR过程。
Merge or Rebase
之所以提及这两个合并方式，是因为会存在有些项目的主分支只希望保留提交点，而不是包含合并分支等信息。
Merge
merge是最基础的分支合并方法了，简单高效。如果项目主分支不在乎合并时额外产生的分支信息，就可以一股脑地使用这个合并方式。
merge会产生分支交叉，这在开发测试分支dev中并不会成为问题，但在主分支上，就会导致节点信息不明。
这对于排查问题时，是一种困扰，因为会看到很多额外的分支信息。
Rebase
rebase的原理是，对比当前分支的节点和目标节点的提交树，找出相同的最后一个节点，将当前分支之后的提交记录平移到最后一个节点之后，从而形成一棵直线的提交记录树。
而在rebase之后，就会遇到一种情况，因为你的远程分支是还未rebase过的，所以远程分支的提交记录是会和本地分支不同，而这时候就需要进行本地分支的强推git push --force
强推这个操作，是会在很多情况下都可以作为解决分支问题的最好方法。
但是你要知道你在做什么分支修改操作。
合并冲突
多少都会在开发中会出现合并冲突的情况，哪怕分工再明确的情况下，但功能组件的耦合，就会让合并冲突的情况出现。
我所遇到的合并冲突分为两种：代码冲突和分支自我合并冲突
代码冲突
在上述的merge或者是rebase中，都会存在代码冲突，这个是任何合并方式都无法避免的。
解决代码冲突的最佳方式是——适应它
只要清楚你这次修改了什么，而剩下的功能保持不变，解决代码冲突并不是很难。
分支自我合并冲突
这个冲突会导致提交树上会额外产生一条分支自己合并自己的信息，而这一局面的产生是因为多人在相同分支上进行开发。
是的，这很奇怪。
正常来说，一人一分支是很基本的。但是总会有一些人对Git的掌握并不是很熟悉，而对此最简单粗暴的方法就是在同一分支上开发。
解决这一问题的方法是——教会不熟悉工作流的人又或者是在每一次提交前进行拉取最新分支代码。
分支提交记录冲突怎么解决？
再好的工作流，也无法避免的是会出现分支提交记录冲突。
人非圣贤，孰能无过
那么就需要代码回退——reset和revert
Reset
git reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本。
所以该指令会真正地撤销一些错误的提交或者是不应该存在的提交信息。
当发生分支自我合并冲突的时候可以采用，但是需要注意：不同参数会让回退效果不同
-
reset --soft HEAD~只改变HEAD，修改的记录依旧在暂存区。 -
reset [--mixed] HEAD~改变HEAD与上次提交——默认参数 -
修改的记录不在暂存区，但工作目录中会保留文件的修改。
-
reset --hard HEAD~会将HEAD回退到某个节点。 -
这意味着在选定节点之前的提交都将会丢失。
Revert
如果你需要保留之前的提交记录，而又想改变因为之前提交记录所引发的代码问题，就采用git revert。
它相当于你回到某个非HEAD节点出处，然后进行代码再一次的更改，从而进行提交代码，产生一个新的节点，而它将保留之前的代码提交记录。
这不同于reset的直接回退节点树，它更像是一个恢复某个节点所导致的异常问题。
----END
推荐阅读
看完一篇文章就该休息了，别看了，推荐个毛啊。该走走动动，放松眼睛和拉伸身体。工作虽重要，但生活才是人生的重点
