GIT工作流

前言: 关于git的使用, 之前就已经写过一篇博客了: http://www.cnblogs.com/0zcl/p/6874588.html. 看完这篇博客, 你就基本可以使用git了. 这种使用, 仅限了一两人的开发. 如果团队有多人, 而且位置较分散. 那这开发就更需要规范了. 因此, 这篇博客来说一下GIT工作流.

 

本来以为我用git命令行可以解决GIT工作流上的问题,但其实只用命令行还是蛮困难的。下面先看看GIT的规范, 这部分比较无聊, 下面会图文并茂的, 好吧. 如果你瞄了一眼, 觉得这SB博客, 写得太low了, 然后就关掉这篇博客, 我感觉还是错过一些东东.

一、提交规则

[feature] 新增功能、更新的提交,例如“[feature] add a new data layer for reading jpeg images”

[bugfix] bug修正的提交,有bugid的补充bugid,例如“[bugfix] now data layer reads single-channel images correctly”

[optimize] 优化的提交:性能等方面,feature分之下的单次优化要指明,优化分支下的用[feature]即可

[refactor] 代码等重构的提交,feature分之下的单次重构要指明,重构分支下的用[feature]即可

  • 每次提交应该只能有一个修改,不能将多个逻辑修改放在一个提交中;不可将一个逻辑修改分成多个提交
    • 例如: 同时修复一个bug,同时做了重构或优化,就要把提交分成两个(bugfix、refactor/optimize)。
  • 每次merged到develop分支的代码必须为可运行的,并且保证多平台可用
  • 多人协作过程中如果在开发同一个feature,不可以在同一个feature分支进行开发,需要各自拉出新feature分支独立开发,完成后merge到共同的feature分支
  • 每日至少一次Git提交,防止代码丢失
  • feature分支在完成后合并到develop

 

二、版本号的定义

A.B.C。例如1.1.0。按照功能来定:

  • 如果是大的版本更新,则A+1,并且B和C都设置为0;
  • 如果是小的版本更新,则B+1,并且A不变,C设置为0;
  • 如果是修复bug的版本更新,则C+1,并且A和B都不变。

 

三、Git工作流

添加一个工程文件以后,点击:(仓库)——(git flow)——(初始化仓库)

  • 这个的目的是为了方便git各种分支的自动生成,同时也是为了后续工作流的方便使用。

develop

当前版本最新开发进展,未测试或者测试中,对于单人开发小模块可以直接提交,多人协作及大模块必须通过合并具体功能子分支,接受来自feature,release,hotfix的合并。

  • 创建分支必须通过(git flow)——(建立新的功能)从develop来进行

feature分支

这个分支主要是为了各种研发方案执行使用。(必须推送远端,完成feature后合并到develop,以及测试下是否可以执行)

  • 分支命名以版本号+开发者+模块的形式来,例如:feature/1.0.0_aidy_newfeature。
  • 当分支特性开发完成后合并到develop,主要是通过(git flow)——(完成功能)来进行合并,或者手动合并。
  • 当出现合并冲突时,记得与冲突者当面一起沟通与合并,并确认效果ok。

release分支

这个分支主要是给研发方案差不多确定时使用,主要是为了fixbug等。(完成feature后,必须推送远端,以及测试下是否可以执行)

  • 这个分支只来自develop,当研发差不多了以后,就开始做release分支。
  • 命名为版本号,例如1.0.0。主要是通过(git flow)——(建立新的发布版本)来进行。
  • 当realease分支差不多了,就通过(git flow)——(完成发布版本)来进行。并会打一个版本号的标签。
  • 完成后并入develop和master。

hotfix分支

主要用于最新发布版本的bug修复。

当前版本

  • 就通过(git flow)——(建立新的修复补丁)来进行。
  • 当完成以后,通过(git flow)——(完成新的修复补丁)来进行合并。
  • 当出现合并冲突时,记得与冲突的修改者当面一起沟通与合并,并确认效果ok

 

以上来自GIT规范,然而看完GIT规范感觉还是没有顿悟的感觉。so,必须得会使用smartgit呀。

 

四、使用SmartGit

看完GIT规范,你已经知道,feature分支是平时开发功能用的,完成feature分支开发后,合并到develop分支,合并成功后,删除该feature分支。这用smartgit可以轻松实现,用命令行的话是比较麻烦,但也可以实现呀。现在的问题是,用smartgit如何轻松实现创建feature分支,删除feature分支?

点击Git-Flow,再点击configure,可出现如下图:如果你找不到下图这个界面,那必然是你操作的姿势有问题。

看到没有,神奇呀,在上图中,你只需点击OK,GIT就会自动帮你创建feature, release, hot-fix, develop分支。这超牛逼的。这步操作很重要。完成这步操作后,会出现develop分支,此时需要把develop分支推到远程。

正常情况下,你远程仓库应该有两个分支了,分别是master和develop分支。如果没有,把它们推到远程

啥,不知道怎么push?有两种方式,在上图的左下角的Branches窗口下,你可以点击master分支,然后鼠标右击,再点击push to ;也可以在左下角的Branches窗口下,双击要push的分支A,此时分切换到A分支,然后再点击上图左上方的Push推到远程。

 

五、feature分支的使用

OK,此时远程仓库应该有两个分支master/develop,然而这还远远不够呀,你看到同事的项目有一个feature分支。so,你肯定也是需要feature分支的。

点击Git-Flow,会出现下图。如果没出现Start Feature; Start Release这些,必然是你最开始的configure有问题。

点击Start Feature来创建一个feature分支,分支命令要参考命名规范。

现在你已经有一个feature分支了。在该分支提交些东西,commit后,提交到远程。你会惊喜的发现远程的仓库出现feature分支

 

现在你可以不断地开发,提交代码到feature分支上,但feature分支只负责一个功能的开发而已,当这个功能开发完成后,必然需要把该feature分支删除

简单粗暴地说,就是当feature/0.0.2_zzy_example分支负责的功能开发完毕时,需要把feature分支合并到develop分支,合并完成后,feature分支删除,此时远程仓库就看不到feature/0.0.2_zzy_example分支。

其实smartgit已经帮我们简化了工作。牛逼呀。

当你创建feature分支时,会自动切换到feature分支。完成功能开发后,想把feature分支合并到develop分支,如何做呢?

只需点击Git-Flow,就会出现下图。注意,此时你应该是处于feature分支的:

看到上图的Delete feature branch没,当你合并完成后,就会把feature分支删除。

接下来你需要把develop分支推到远程。你会发现远程的feature分支不见了

以上,是feature分支开发的流程。

 

六、发布版本

今天,团长想考下git方面的操作。给我一个需求:

先来看看GIT规范对于release分支是如何介绍的:

release分支

这个分支主要是给研发方案差不多确定时使用,主要是为了fixbug等。(完成feature后,必须推送远端,以及测试下是否可以执行)

  • 这个分支只来自develop,当研发差不多了以后,就开始做release分支。
  • 命名为版本号,例如1.0.0。主要是通过(git flow)——(建立新的发布版本)来进行。
  • 当realease分支差不多了,就通过(git flow)——(完成发布版本)来进行。并会打一个版本号的标签。
  • 完成后并入develop和master。

第一步

先创建一个release分支:点击Git-Flow,再点击start release:

输入release分支名,分支名参考GIT规范。

 

第二步:可以在release分支commit, push到远程。此时你的远程除master, develop外,应该得有一个release分支

 

第三步:发布版本

点击finish,就会发布版本啦,这里需要给版本打一个tag,tag默认会自动显示为你的版本号。同时会把release合并到master与develop分支。再同时发布之后,会删除该release分支。

 

此时远程如下显示:没有release分支。多了一个Tags版本:

至此,团长交待的任务完成!

 

 

七、附本人测试用了GIT分支图:

 

 

八、总结:

  1. 由于最开始就没用好smartgit,比如下面这张图的操作。之前就没用到,导致后面的操作不顺。
  2. 不要用命令行,不要用命令行,不要用命令行。命令行操作add, commit, push还可以,但对于分支操作,版本发布,用smartgit,用smartgit,用smartgit。
  3. 我想git这块我顿悟了。佛系佛系,喝怀奶荼冷静一下。

 

posted @ 2018-02-13 00:04 前程明亮 阅读(...) 评论(...) 编辑 收藏