Git提交规范流程和解决冲突个人理解篇

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

在讨论规范之前，我们需要定最基本的要求

团队内保持良好的代码格式便于易读和维护，最主要减少不必要的代码冲突（建议统一使用开发工具（idea）的代码格式化）。
提交任何代码必须确认代码可运行
提交的代码必须移除无用的包路径引用和无用的依赖，尽量不要使用过期的方法或者类

1 . commit message规范

规范格式:

<type>: <subject>

type

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

subject

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

举例：

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

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

Git分支

master （生产环境）部署某个uat功能到准生产的时候合并到master，只允许uat分支合并/cherry-pick。
uat （测试环境）部署某个feature分支到测试的时候合并到uat，只允许feature分支合并。
feature/xxxx (特性分支) 开发一个功能或者修改bug的时候合并/提交到feature
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 protected]</div>
=======
<div id="footer">
 please contact us at [email protected]
</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目录，你懂得。

0条评论

放牧的风