: 

git clone -b dev/xx  feature/项目编号

git checkout feature/项目编号

git pull

git checkout dev/xx

git add .

git commit -m 'fix:修改了XXXXX'

git commit -am 'fix:修改了XXXXX'

git checkout feature/项目编号
git pull

git checkout dev/xxx

git rebase feature/项目编号

git  push  origin dev/xxx

git status

<<<<<<< HEAD:index.html
contact : email.support@github.com

以上文件内容表示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的记录直接操作即可。

关于Git提交规范有哪些问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。