最近项目中代码管理学习
2017-07-13 20:49
169 查看
之前项目用的都是SVN进行代码管理的,最新的两个项目開始用git了。非常早之前就開始接触git。可是一直没有正规的使用过,所以对git的命令并非非常熟悉,基本上的命令都是使用诸如clone、checkout、add、commit之类的命令。没有使用过创建分支(branch)和打tag之类的操作。眼下项目中常常出现一种情况:项目開始的时候我们都在master分支上开发,然后等到一个阶段完毕之后我们会公布这个版本号,然后再创建一个develop分支。接着在develop分支上开发,然后对master分支公布,打tag,接着再继续在develop分支上开发,可是在开发过程中之前公布的版本号可能出现一些bug。这时候须要紧急的修复。
在当前的项目中,我逐渐開始接触到了项目中的代码管理,我们普通情况是保持三个分支:master分支,release分支和develop分支,master分支上的代码始终是稳定的,也就是当前最新公布的版本号,release分支上的代码是给QA部署使用的,开发者不能改动。开发仅仅能够向develop分支上提交代码。然后自測完毕之后再将develop上的代码merge到release分支上通知QA部署QA环境而且測试。当QA測试完毕之后能够公布的时候再将release分支上的代码merge到master,之后能够将master分支上的代码构建。公布,再对当前公布的版本号打tag。
这种一套流程中。当出现上面的问题时须要基于之前公布的版本号进行紧急修复,这是就在master上拉取一个分支,由于master上的代码就是当前公布版本号的代码,比如称为XXX-hotfix分支。然后在这个分支上做修复,修复完毕之后再将该分支合并到release中由QA部署測试,成功之后还须要将这个版本号再合并到master上和develop上。然后再对master上的分支打tag,构建公布。
所以在当前的代码管理中通常会存在3个分支,最多存在一个hotfix分支,master分支上的代码总是当前上线版本号的代码,开发仅仅可以在develop分支上提交代码,所以冲突基本上都是在提交develop时候产生的,develop上合并到release和master上的时候基本上都可以自己主动合并的,当然假设存在多个开发版本号的情况须要再进行讨论。
曾经项目中没有这么规范的流程。基本上也都是一个人开发,然后提交完毕之后就交给QA測试了。没考虑到这些规范,当然随着规范的建立也多也一些繁琐的交互,可是这样长久下来还是效率比較高的。
最后今天在使用git的时候不小心出现的一个问题,当我在hotfix分支上开发測试完毕之后须要merge到develop分支和master分支上。当前我的git bash处于develop分支,我本来想pull一下最新的版本号。却写成了git pull origin hotfix,这样子就把hotfix分支上的内容合并到了develop上。事实上这个操作和merge几乎相同,然后我运行git
push origin develop之后发现了develop上的最后一次提交的message是这种:Merge branch 'hive-hotfix' of https://xxx.git.com.cn/git/xxx/xxx into develop。这个commit的message应该是git自己主动生成的,这就意味着当我把另外一个分支pull到当前的分支上之后运行了代码合并操作而且将本次合并之后的内容commit了。
然后吸取了教训,切换到master分支,再次merge hive-hotfix分支,然后再push
origin master。查看master上的commit记录发如今hive-hotfix中的提交记录也都提交上去了。
所以在merge的时候不不过代码的merge,还是提交每个的commit,可是直接运行pull的时候则不会,因此下次须要警惕,一定不能在一个分支上pull另外一个分支的内容。而是用merge。
在当前的项目中,我逐渐開始接触到了项目中的代码管理,我们普通情况是保持三个分支:master分支,release分支和develop分支,master分支上的代码始终是稳定的,也就是当前最新公布的版本号,release分支上的代码是给QA部署使用的,开发者不能改动。开发仅仅能够向develop分支上提交代码。然后自測完毕之后再将develop上的代码merge到release分支上通知QA部署QA环境而且測试。当QA測试完毕之后能够公布的时候再将release分支上的代码merge到master,之后能够将master分支上的代码构建。公布,再对当前公布的版本号打tag。
这种一套流程中。当出现上面的问题时须要基于之前公布的版本号进行紧急修复,这是就在master上拉取一个分支,由于master上的代码就是当前公布版本号的代码,比如称为XXX-hotfix分支。然后在这个分支上做修复,修复完毕之后再将该分支合并到release中由QA部署測试,成功之后还须要将这个版本号再合并到master上和develop上。然后再对master上的分支打tag,构建公布。
所以在当前的代码管理中通常会存在3个分支,最多存在一个hotfix分支,master分支上的代码总是当前上线版本号的代码,开发仅仅可以在develop分支上提交代码,所以冲突基本上都是在提交develop时候产生的,develop上合并到release和master上的时候基本上都可以自己主动合并的,当然假设存在多个开发版本号的情况须要再进行讨论。
曾经项目中没有这么规范的流程。基本上也都是一个人开发,然后提交完毕之后就交给QA測试了。没考虑到这些规范,当然随着规范的建立也多也一些繁琐的交互,可是这样长久下来还是效率比較高的。
最后今天在使用git的时候不小心出现的一个问题,当我在hotfix分支上开发測试完毕之后须要merge到develop分支和master分支上。当前我的git bash处于develop分支,我本来想pull一下最新的版本号。却写成了git pull origin hotfix,这样子就把hotfix分支上的内容合并到了develop上。事实上这个操作和merge几乎相同,然后我运行git
push origin develop之后发现了develop上的最后一次提交的message是这种:Merge branch 'hive-hotfix' of https://xxx.git.com.cn/git/xxx/xxx into develop。这个commit的message应该是git自己主动生成的,这就意味着当我把另外一个分支pull到当前的分支上之后运行了代码合并操作而且将本次合并之后的内容commit了。
然后吸取了教训,切换到master分支,再次merge hive-hotfix分支,然后再push
origin master。查看master上的commit记录发如今hive-hotfix中的提交记录也都提交上去了。
所以在merge的时候不不过代码的merge,还是提交每个的commit,可是直接运行pull的时候则不会,因此下次须要警惕,一定不能在一个分支上pull另外一个分支的内容。而是用merge。
相关文章推荐
- 最近项目中代码管理学习
- 最近项目中一些关于代码编写管理的一些思考
- 近期项目中代码管理学习
- 张孝祥老师交通灯管理系统的学习笔记 在做一件事时,首先要明确要达到什么效果。有目的性。就软件项目来说就是,首先要看的就是项目所提出的项目要求。做项目,不急于写代码,先把问题搞清楚,把要求分
- 关闭 晓K的专栏 我的学习历程 目录视图摘要视图订阅 赠书 | 异步2周年,技术图书免费选 每周荐书:渗透测试、K8s、架构(评论送书) 项目管理+代码托管+文档协作,开发更
- 关闭 晓K的专栏 我的学习历程 目录视图摘要视图订阅 赠书 | 异步2周年,技术图书免费选 每周荐书:渗透测试、K8s、架构(评论送书) 项目管理+代码托管+文档协作,开发更
- WINCE应用的UI实现方案 —— 下篇:代码一小步,项目进度管理一大步
- 【原创】如何去掉有源代码管理的项目中的相关信息
- 最近设计了一个生成asp代码的程序,同时也可以作为数据库管理查询的软件,发两张图,等完全做好了,给大家共享!
- 最近设计了一个生成asp代码的程序,同时也可以作为数据库管理查询的软件,有兴趣的朋友可以去下载!
- 项目管理学习笔记一
- UML及项目管理建模学习心得1
- 代码管理与项目管理的在线服务——CSDN外包实践(34)
- 微软项目管理[EPM]数据库剖析1:如何取得全局项目有哪些自定义的大纲代码定义
- 项目管理学习一:鲜为人知的软件项目管理原则
- 最近一个小web项目(主站web管理工具)想到的一些东西
- 这是我最近一个项目--星级酒店管理的介绍:
- 微软项目管理[EPM]数据库剖析2:如何取得全局项目中某个大纲代码的列表值
- 代码管理与项目管理的在线服务——CSDN外包实践(34)
- 项目管理学习资料(经典)