Git提交规范流程和解决冲突实际使用

前言：GIT对于咱们程序员来讲是吃饭的工具，本篇主要是针对提交和分支以及对于大多数程序员闻风丧胆的冲突一些我的看法，若是有啥不对的或者大家公司git提交流程欢迎下方评论。

在讨论规范以前，咱们须要定最基本的要求

1.团队内保持良好的代码格式便于易读和维护，最主要减小没必要要的代码冲突（建议统一使用开发工具（idea）的代码格式化）。

2.提交任何代码必须确认代码可运行

3.提交的代码必须移除无用的包路径引用和无用的依赖，尽可能不要使用过时的方法或者类

1 . commit message规范

规范格式:

<type>: <subject>

复制代码

**type  **

• feature: 新功能（feature）
• fix: 修补bug、style等
• refactor: 重构（即不是新增功能，也不是修改bug的代码变更）
• test: 增长测试 chore: 构建过程或辅助工具的变更

subject

提交目的的简短描述，描述作了啥或者改了啥，若是有团队管理工具(issue ,JIRA)或者产品需求，必须之内部命名的需求代号做为描述信息的一部分，方便查看日志，合并和cherry-pick。

举例：

1. feature:开发完成#代号 XXX.XXX需求
2. fix:修改 #代号 XXXX查询问题

2. 提交规范以及GIT开发流程

**Git分支 **

1. master        （生产环境）    部署某个uat功能到准生产的时候合并到master，只容许uat分支合并/cherry-pick。
2. uat              （测试环境）    部署某个feature分支到测试的时候合并到uat，只容许feature分支合并。
3. feature/xxxx  (特性分支)      开发一个功能或者修改bug的时候合并/提交到feature
4. dev/xx           (本地开发版本)

在开发以前，须要在master分支上切一个以需求,BUG,重构.......命名feature分支 ，好比  feature/项目编号（BUG的代号）

2.1  本地没有项目，克隆代码的并切换到开发分支

克隆并在须要开发的feature分支上建立本地dev开发分支，本地分支能够以dev/本身标识的英文 命名。

git clone -b dev/xx  feature/项目编号
复制代码

2.2  本地有项目，切换开发分支

为了不本地分支与远程不一致，须要切换到 feature/项目编号分支，更新一下。

git checkout feature/项目编号

git pull
复制代码

再在 feature/项目编号上切出本身的开发分支

git checkout dev/xx
复制代码

2.3 提交代码

注意:必须把不须要提交的后缀或者文件添加到和.git同目录的 .gitignore文件中

添加修改的文件到暂存区(staging area)

git add .   
复制代码

将修改后的文件提交到本地的版本库中

git commit -m 'fix:修改了XXXXX'
复制代码

也能够两步合成一步操做

git commit -am 'fix:修改了XXXXX'
复制代码

提交代码我我的是建议最好使用idea或者其余git图形化界面来操做勾选须要添加的文件，或者操做。

git后面的图标对应的意思

• 第一个是 git 拉代码操做按钮
• 第二个是 git 提交操做按钮
• 第三个是 git log操做按钮
• 第四个是 git revert操做按钮

首先点击git提交按钮

点击提交按钮就能清楚的看到git status的状况，有修改的有哪些文件，哪些文件须要提交git，哪些文件不须要提交git。若是临时或者不当心动的地方可使用revert恢复到修改前。

若是这个文件不须要修改，或者不当心空格等操做，直接使用 revert恢复

若是这个文件是项目启动时候生成的，好比项目导出的excel或者log日志，直接使用 delete删掉

小技巧:你们在开发过程当中，能够随时进入上图的提交界面直观的看到哪些文件有变更，更方便和更高效的管理本身修改的内容，其余桌面图形化也能够，好比  TortoiseGit，Source Tree，以及git自带的两个 gitk 和 git-gui (在git目录里输入命令)。

2.4 推送到远程分支

在推送本地分支dev到远程dev的时候，须要先切换到 feature/项目编号分支,merge远程分支代码。

git checkout feature/项目编号
git pull

复制代码

再切换到本身的开发分支dev/xxx

git checkout dev/xxx
复制代码

rebase feature/项目编号到本身dev/xxx，主要做用就是检查是否有冲突。

git rebase feature/项目编号
复制代码

没有冲突，直接push dev/xxx到远程 dev/xxx

git  push  origin dev/xxx
复制代码

若是有冲突，能够在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件

git status
复制代码

全部合并中冲突而待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你能够打开这些包含冲突的文件而后手动解决冲突。

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> dev/xx:index.html
复制代码

以上文件内容表示head指向的(也就是rebase的那个分支)版本和下面dev/xx指向的版本有冲突

=======为分割线，上半部分是head指向的分支的版本的代码，下半部分是dev/xx分支所指向的版本的代码

上述的冲突解决方案仅保留了其中一个分支的修改，而且<<<<<<< , ======= , 和 >>>>>>> 这些行须要被彻底删除。

修改完成以后须要操做

git add .

复制代码

使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些本来有冲突的文件，Git 就会将它们标记为冲突已解决

而后继续rebase操做:

git rebase --continue
复制代码

一直循环rebase --continue，直到rebase成功

而后push

git  push  origin dev/xxx
复制代码

最后登陆gitlab或者coding的web管理，提交合并请求，将远程分支dev/xxx和远程分支feature/项目编号分支合并，合并以后才能表示你的提交完成了。等feature分支全部的人开发完成并测试经过以后，再将feature合并到uat进行上线测试。

如今咱们看看借助咱们神器idea来解决冲突。

在操做 merge，rebase,cherry-pick   ,当有冲突的会弹出conflicts

最好不要直接选择采用远程仍是采用本身修改的代码，仍是单独点击文件选择每一行的变更

解决完成以后apply以后直接push就能够了。

总结:

对于git而言，只有push和pull操做才会和远程打交道，其余的命令都是本地完成的，也就是说只有pull,push或者在git平台上直接发起远程分支和远程分支合并请求的时候才真正知道有木有冲突。即便本地rebase feature ，但仍是没有办法保证dev和feature没有冲突，由于你rebase的时候不能表明你当前本地feature分支和你发起合并请求时候的feature分支的代码彻底一致，因此rebase feature 只是提早下降了合并feature时候的冲突。

对于git操做的流程，你们使用习惯有些不同，实际上怎么操做都没有错，若是公司，团队有所承认的规范，仍是按照规范来。

**常见的提交方式 **:

1.直接在feature分支开发，每一个人在commit以前pull（git fetch + git merge）一下新的feature的代码，而后有冲突一次性解决以后 add. commit  push。

2.直接在feature分支开发，每一个人先commit到本地分支，而后pull --rebase （git fetch + git rebase）当前新的feature的代码，而后有冲突解决以后 add.    push。

3.就是我上面写的严格操做，每一个人都有一个本身命名的本地开发分支，经过和本地的将要合并的本地分支merge或者rebase来解决冲突，而后经过web平台的请求来合并。

4.欢迎你们提供更多牛逼哄哄的方式。。。。。。。

第一种，是最简单的，最多见的操做的方式，这种方式容易在解决冲突的时候把本身修改的代码弄丢，操成没法挽回的结果。（你们能够借助idea本地的历史回滚也是能够）

第二种，先提交，再拉代码rebase，能够保证本身的代码提交到了本地分支，无论以后怎么瞎操做改代码都不会丢失这条已提交的commit。

第三种，操做有点复杂，虽然绕了一点弯路，可是和第二种相比较，主要区分就是feature分支允不容许直接提交。若是容许，那feature合并的权限控制就放在合并到uat的这个环节。

简单的理解:GIT的操做无非就****是拉代码，推代码，合并代码，在每一步和远程分支打交道的操做才会真正出现冲突。可是何时提早解决冲突或者以什么方式解决冲突有不少种。

无论你用什么图形化工具，可是咱们须要先搞清楚git的基本命令，以及每一步图形化工具操做的背后git操做的命令。

警告：有没push的代码不要删.git目录，你懂得。

没有解决冲忽然后强行push的后果，哈哈哈，我笑了

**彩蛋; **

上面提交的知识讲完了，咱们拓展一下知识

1.reset怎么用？

用法：

git reset --mixed/--hard/--soft c27894c06a2cc23e4097a93013cf640cc4fd527d


git reset –mixed HEAD~1 
回退一个版本,且会将暂存区的内容和本地已提交的内容所有恢复到未暂存的状态,不影响原来本地文件(未提交的也 
不受影响) ,也就是恢复到add以前
git reset –soft HEAD~1 
回退一个版本,不清空暂存区,将已提交的内容恢复到暂存区,不影响原来本地的文件(未提交的也不受影响),也就是恢复到commit以前
git reset –hard HEAD~1 
回退一个版本,清空暂存区,将已提交的内容的版本恢复到本地,本地的文件也将被回退的版本替换，也就是恢复到没开发以前


复制代码

首先强调已上线的项目reset不建议使用，也禁止使用，为啥这么说呢？

git自己就是存储代码全部历史记录，无论你是错误提交仍是提交的代码有BUG，应该是在错误的基础上再commit一条你修正的提交，而不是撤销你已经提交到远程分支的代码。

若是你不当心把一部小电影提交到了GIT，或者你想“删代码跑路“，再或者你的改动操成了成千上万的BUG， reset以后，须要强制push到远程分支，reset点以后的远程分支的提交的记录将永久消失。

2.我想合并uat分支的某次提交以前的代码

 git  checkout -b uat20190711 c27894c06a2cc23e4097a93013cf640cc4fd527d 
复制代码

能够push到远程再和其余分支合并或者切换其余分支rebase直接push

3.cherry-pick这么用？

git  cherry-pick -x -n 017822ece3049d3f46c72cabf32dee9f44dd15cc
复制代码

将某一次提交的改动直接在当前分支上作修改，而后提交便可，因此提交的commit就须要写清楚你提交的意图。

-x 保留原做者  -n 不自动提交

图形化工具截图，本身摸索，都一个样，找到某一条commit的记录直接操做便可。

博客地址：my.oschina.net/wangnian