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。
举例:
- 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.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的记录直接操作即可。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
百人研发团队的难题:研发管理、绩效考核、组织文化和OKR
什么是研发团队?简单的说,你熟悉的那帮穿格子衬衫,以程序员为核心组成的团队,就是研发团队。 本来,你以为格子男们是很乖很闷骚的那种,管理和协作起来比销售和业务简单很多,而实际情况是,格子男们并不那么容易管理,面向代码世界的复杂度,可能远比面向财物世界的复杂度还要高。 作为致力于团队协作的公司,我们研究了很多国内和海外牛逼公司的研发模式和研发管理,例如OKR在谷歌、Facebook的应用,Uber的高效会议制度,阿里的绩效体系,腾讯的产品流程。 除了在自身团队做了N次不同的试验和反思,我们也想将很多不错的经验分享给用户。要谈清楚方法,就先了解清楚问题,研发管理之所以令人头疼,核心的问题无外乎以下一些方面。 研发管理的典型问题 1. 难以KPI化和考核 任正非有句名言:钱分好了,管理的大部分问题就解决了。我对此深表同意,可问题是,怎么能分好钱确实非常考验能力、经验和智力的。研发之难,恰恰难在无法KPI化工作本身,所有那些试图KPI化工程师和码农的做法,最终结果都啼笑皆非、面目可憎、吃力不讨好。 在我过去经历,还有客户实际的研发管理里,试图KPI化研发工作一直是不同团队努力的尝试,包括和不限...
- 下一篇
最强开源微服务框架,全网独家整理
诞生于 2014 年的“微服务架构”,其思想经由 Martin Fowler 阐述后,在近几年持续受到重视,理论与相关实践都不断发展,目前它已经成为了主流软件架构模式。 关于微服务架构是什么,没有一个明确的定义,每个实践者有自己的理解,但是有人给出的一个公式值得思考: 微服务架构 = 80% 的 SOA 服务架构思想 + 100% 的组件化架构思想 + 80% 的领域建模思想 微服务架构的优点很多,比如它解耦业务,提供更高的灵活性,允许在服务频繁发版的同时保持系统其它部分的可用性与稳定性;解耦编程语言,针对不同业务可以使用更加合适的语言进行开发;解耦开发团队,不同团队各自负责一个微服务,互不影响,加速交付。 关于微服务架构,网上资料相当多(因为现在很火,各家都有实践案例分享),读者可以另行查阅,这里不赘述。 下边为大家列举了当前最为火热,最常被人提及的开源微服务开发框架,希望对开发者有一定的帮助(点击项目名,可以直接跳转介绍页): Spring Cloud Spring Cloud 为开发者提供了分布式系统配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果