Git:工作流程Git Flow

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/chaiyu2002/article/details/80945211

点击这里,可以查看原帖,原帖会不断完善和更新。

前言

参考:https://nvie.com/posts/a-successful-git-branching-model/, 这篇帖子是10年发表的,而我大概是08、09年接触的Git,当时因为刚刚花了好大气力研究明白SVN的流程,所以对Git很排斥,这也是我工作中一直以来的一个问题,因为在一项老技术上花了太多气力,而导致对新技术的出现本能地产生很大的排斥。如果当时仔细去研究一下Git,应该会发现Git不是来革我们这些SVN拥趸的命,而是提供完善和丰富了SVN的功能。

概述

从CVS到SVN,再从SVN到Git。
从中心化到去中心化的中心化(Decentralized but centralized),这句话挺有挺有深意。

分支

长期分支

项目存在两个长期分支:

  • 主分支master。
  • 开发分支develop或者dev。

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

这里的HEAD是Git的一个指针,指向当前的分支上。
上面的话的意思大概是master分支总是指向“等待上生产”状态的代码。develop分支往往是最近交付的开发修改。这个过程是和原本的SVN工作流是很接近的,一个开发分支,一个线上分支。开发完,测试后,发布到线上。SVN流程推荐在测试时分叉一个branch出来进行测试,这个时候不影响trunk上业务的继续开发,这个工作流没有这么明说,但是因为Git的灵活性,建立一个临时的测试分支也是没有问题的。Git好就好在非常灵活,不过也正是因为如此,导致了一些问题,之前有一个小朋友,把所有的功能分支都保存了下来,还说这样会更加方便,我很难理解,这样怎么会方便呢?每个人分支都需要不断同步。灵活也应该是相对的,在一个相对固定的流程下,适当的灵活,是可以提高效率的。

支持分支

原文叫做supporting branches。这里面的每一个分支都有指定的目的和约束的规则,如何产生和如何合并。
- Feature branches
- Release branches
- Hotfix branches

功能分支

可以产生于:
develop
必须合并到:
develop
分支命名约定:
除了master, develop, release-, or hotfix- 都可以,前面几个作为保留。

功能分支用于开发未来的一项功能,目标的发布此时可能还不确定。这个分支最终会被合并回develop(采用了)或者被抛弃掉(不采用)。
功能分支更多存在于用户仓库,而不是origin仓库。

创建:

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

合并回develop:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

对于–no-ff,参考:https://git-scm.com/docs/git-merge,有待更进一步的解释。

发布分支

可以产生于:
develop
必须合并到:
develop和master分支
分支命名约定:
release-*

我理解的,这里主要用于准备一个发布版的功能已经开发完成,等待一些信息最后的确认,为了不影响下一个开发版的正常进行,打出一个发布分支。

创建一个发布分支

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

结束一个发布分支
合并回master分支

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

合并回develop分支

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

删除原分支

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

热修复分支

可以产生于:
master
必须合并到:
develop和master分支
分支命名约定:
hotfix-*

主要用于对线上代码进行热修复用,线上代码出现了问题,开出一个分支进行修复,等修复完成,合并回master和develop分支。

创建

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

提交

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

结束
合并回master

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

合并回develop

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

删除

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).
阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页