Java架构师学习资料—Git Flow

在Java程序开发中的定制开发规范,想要把项目正规高效的跑起来。引入 Git 版本控制,Git-Flow 便成为了首选。今天动力节点Java学院来带你了解一下。
1、为何使用 git-flow
当在团队开发中使用版本控制系统时,商定一个统一的工做流程是相当重要的。 Git 的确能够在各个方面作不少事情,然而,若是在你的团队中尚未能造成一个特定有效的工做流程,那么混乱就将是不可避免的。
基本套路:你能够定义一个彻底适合你本身项目的工做流程,或者使用一个别人定义好的。
2、安装 git-flow
咱们使用 Homebrew 来安装 git-flow:
1.brew install git-flow
以后,经过 git-flow 来初始化项目:
1.git flow init
这时候就会有一些配置的操做,先默认操做:
1.Initialized empty Git repository in /Users/jartto/Documents/git-flow-demo/.git/
2.No branches exist yet. Base branches must be created now.
3.Branch name for production releases: [master]
4.Branch name for "next release" development: [develop]
5.
6.* Please tell me who you are.
7.
8.Run
9.git

  1.  git config --global user.email "you@example.com"
  2.  git config --global user.name "Your Name"

12.
13.to set your account's default identity.
14.Omit --global to set the identity only in this repository.
15.
16.fatal: unable to auto-detect email address (got 'jartto@bogon.(none)')
17.fatal: Not a valid object name: 'master'.
18.error: pathspec 'develop' did not match any file(s) known to git.
19.
20.How to name your supporting branch prefixes?
21.Feature branches? [feature/]
22.Release branches? [release/]
23.Hotfix branches? [hotfix/]
24.Support branches? [support/]
25.Version tag prefix? []
须要强调一点:git-flow 只是封装了 git 的命令。
因此在咱们初始化的时候,对仓库并无其余改动,只是建立了几个分支。固然,若是你不想继续使用 git-flow ,那么只须要简单的停用 git-flow 的命令便可,不须要修改或者删除任何文件。
为了验证一下,咱们看下目前的分支,执行:
1.git branch
输出:
1.* develop架构

  1.  master

很简单, develop 分支是咱们平常开发的分支,会有不少改动。而 master 主要针对线上分支,下面会细说。
这里补充一点,咱们能够经过 help 命令来查看用例。
1.git flow help
输出以下:
1.usage: git flow <subcommand>
2.
3.Available subcommands are:ide

  1.   init      Initialize a new git repo with support for the branching model.
  2.   feature   Manage your feature branches.
  3.   release   Manage your release branches.
  4.   hotfix    Manage your hotfix branches.
  5.   support   Manage your support branches.
  6.   version   Shows version information.

10.
11.Try 'git flow <subcommand> help' for details.
若是我要看 feature 相关命令呢?
1.git flow feature help
使用规范就会列出来:
1.usage: git flow feature [list] [-v]学习

  1.       git flow feature start [-F] <name> [<base>]
  2.       git flow feature finish [-rFk] <name|nameprefix>
  3.       git flow feature publish <name>
  4.       git flow feature track <name>
  5.       git flow feature diff [<name|nameprefix>]
  6.       git flow feature rebase [-i] [<name|nameprefix>]
  7.       git flow feature checkout [<name|nameprefix>]
  8.       git flow feature pull <remote> [<name>]

3、分支模式
git-flow 模式会预设两个主分支在仓库中: 1. master 只能用来包含产品代码 咱们不能直接工做在这个 master 分支上,而是在其余指定的,独立的特性分支中。
不直接提交改动到 master 分支上也是不少工做流程的一个共同的规则。
2. develop 是你进行任何新的开发的基础分支 当你开始一个新的功能分支时,它将是开发的基础。另外,该分支也聚集全部已经完成的功能,并等待被整合到 master 分支中。
图片描述测试

上面说到的这两个分支被称做为长期分支,它们会存活在项目的整个生命周期中。
而其余的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的。它们是根据须要来建立的,当它们完成了本身的任务以后就会被删除掉。
图片描述fetch

4、明确分支功能
1. master 分支 最为稳定功能比较完整的随时可发布的代码,即代码开发完成,通过测试,没有明显的 bug,才能合并到 master 中。请注意永远不要在 master 分支上直接开发和提交代码,以确保 master 上的代码一直可用;
2. develop 分支 用做平时开发的主分支,并一直存在,永远是功能最新最全的分支,包含全部要发布 到下一个 release 的代码,主要用于合并其余分支,好比 feature 分支; 若是修改代码,新建 feature分支修改完再合并到 develop 分支。全部的 feature、 release 分支都是从 develop 分支上拉的。
3. feature 分支 这个分支主要是用来开发新的功能,一旦开发完成,经过测试没问题,咱们合并回 develop 分支进入下一个 release 。
4. release 分支 用于发布准备的专门分支。当开发进行到必定程度,或者说快到了既定的发布日,能够发布时,创建一个 release 分支并指定版本号(能够在 finish 的时候添加)。开发人员能够对 release 分支上的代码进行集中测试和修改 bug。(这个测试,测试新功能与已有的功能是否有冲突,兼容性)所有完成通过测试没有问题后,将 release 分支上的代码合并到 master 分支和 develop 分支。
5. hotfix 分支 用于修复线上代码的 bug 。从 master 分支上拉。完成 hotfix 后,打上 tag 咱们合并回 master 和 develop 分支。
须要注意:
全部开发分支从 develop 分支拉。
全部 hotfix 分支从 master 拉。
全部在 master 上的提交都必要要有 tag,方便回滚。
只要有合并到 master 分支的操做,都须要和 develop 分支合并下,保证同步。
master 和 develop 分支是主要分支,主要分支每种类型只能有一个,派生分支每一个类型能够同时存在多个。
5、关于 Feature 分支
在 Git-flow 中,经过使用 Feature 分支,使得咱们在同一时间开发多个分支更加简单。 咱们接到了一个 Test1 需求,使用 feature start 来启动:
git flow feature start test1
当咱们开始一个新的 feature 开发后:
1.Switched to a new branch 'feature/test1'
2.
3.Summary of actions:
4.- A new branch 'feature/test1' was created, based on 'develop'
5.- You are now on branch 'feature/test1'
6.
7.Now, start committing on your feature. When done, use:
8.this

  1.     git flow feature finish test1

咱们自动切到了 feature/test1 分支下,正好开始咱们的开发,建一个文件先:
1.vi main.js
写入 console.log('hello jartto'); 接着提交咱们的变动:
1.git add .
2.git commit -m 'feat: add console.log'
好了,如今咱们开发完了,结束 feature 开发:
1.git flow feature finish test1
控制台输出了:
1.Switched to branch 'develop'
2.Updating d975789..27e920c
3.Fast-forward
4.main.js | 1 +
5.1 file changed, 1 insertion(+)
6.create mode 100644 main.js
7.Deleted branch feature/test1 (was 27e920c).
8.
9.Summary of actions:
10.- The feature branch 'feature/test1' was merged into 'develop'
11.- Feature branch 'feature/test1' has been removed
12.- You are now on branch 'develop'
这里作了几件事情: 1.将 feature/test1 分支合并到了 develop 分支; 2.删除了 feature/test1; 3.切换到 develop 分支;
须要注意: git-flow 使用的命令是:
1.git merge —no-ff feature/test1
这样,在咱们移除 feature 分支以前,是不会丢失任何历史记录的。
若是你还不了解 --no-ff 相关知识,能够先看看:Git merge 的 –ff 和 –no-ff。
接着,咱们看一下变动记录:
1.git log --oneline
输出:
1.27e920c (HEAD -> develop) feat: add console.log
2.d975789 (master) Initial commit
6、release 分支-版本发布
当咱们开发完毕,须要去发布新版本的时候,咱们可使用:
1.git flow release start 0.1.0
控制台会有一些提示:
1.Switched to a new branch 'release/0.1.0'
2.
3.Summary of actions:
4.- A new branch 'release/0.1.0' was created, based on 'develop'
5.- You are now on branch 'release/0.1.0'
6.
7.Follow-up actions:
8.- Bump the version number now!
9.- Start committing last-minute fixes in preparing your release
10.- When done, run:
11.spa

  1.     git flow release finish '0.1.0'

很清晰,咱们简单说一下: 1.基于 develop 分支新建了 release/0.1.0 分支; 2.切换至 release/0.1.0 分支;
又出现了新问题: 1.这是什么意思: Bumpthe version number now! 2. last-minute fixes 又是什么意思?
那接下来咱们要作什么呢?不着急,按照提示一步步来。
咱们修改了代码,进行add,和 commit 以后,执行:
1.git flow release finish 0.1.0
这个过程当中间可能出现异常:
1.fatal: no tag message?
2.Tagging failed. Please run finish again to retry.
输出:
1.Switched to branch 'develop'
2.Merge made by the 'recursive' strategy.
3.test.js | 0
4.1 file changed, 0 insertions(+), 0 deletions(-)
5.create mode 100644 test.js
6.Deleted branch release/0.1.0 (was 0426707).
7.
8.Summary of actions:
9.- Latest objects have been fetched from 'origin'
10.- Release branch has been merged into 'master'
11.- The release was tagged '0.1.0'
12.- Release branch has been back-merged into 'develop'
13.- Release branch 'release/0.1.0' has been deleted
这里主要有几个操做: 1.首先, git-flow 会拉取远程仓库,以确保目前是最新的版本。 2.而后, release 的内容会被合并到 master 和 develop 两个分支中去,这样不只产品代码为最新的版本,并且新的功能分支也将基于最新代码。 3.为便于识别和作历史参考, release 提交会被标记上这个 release 的 Tag。 4.清理操做,版本分支会被删除,而且回到 develop。
7、Hotfix 线上代码
若是线上代码有问题,这时候你须要紧急修复呢?
咱们可使用 git flow hotfix :
1.git flow hotfix start jartto
看一下执行了什么:
1.Switched to a new branch 'hotfix/jartto'
2.
3.Summary of actions:
4.- A new branch 'hotfix/jartto' was created, based on 'master'
5.- You are now on branch 'hotfix/jartto'
6.
7.Follow-up actions:
8.- Bump the version number now!
9.- Start committing your hot fixes
10.- When done, run:
11.版本控制

  1.     git flow hotfix finish 'jartto'

接着咱们新建了目录:
1.mkdir assets
放入一张图片,修改完毕,提交并结束 hotfix:
1.git add .
2.git commit -m 'fix: assets img'
3.git flow hotfix finish 'jartto'
看一下 git-flow 有哪些操做:
1.Switched to branch 'master'
2.Merge made by the 'recursive' strategy.
3.assets/git-flow.png | Bin 0 -> 25839 bytes
4.1 files changed, 0 insertions(+), 0 deletions(-)
5.create mode 100644 assets/git-flow.png
6.Switched to branch 'develop'
7.Merge made by the 'recursive' strategy.
8.assets/git-flow.png | Bin 0 -> 25839 bytes
9.1 files changed, 0 insertions(+), 0 deletions(-)
10.create mode 100644 assets/git-flow.png
11.Deleted branch hotfix/jartto (was a734849).
12.
13.Summary of actions:
14.- Latest objects have been fetched from 'origin'
15.- Hotfix branch has been merged into 'master'
16.- The hotfix was tagged 'jartto'
17.- Hotfix branch has been back-merged into 'develop'
18.- Hotfix branch 'hotfix/jartto' has been deleted
查看一下目前的 Tag 状况:
1.git tag
正是咱们上面添加的两个标签:
1.0.1.0
2.jartto
总结一下: 1.完成的改动会被合并到 master 中,一样也会合并到 develop 分支中,这样就能够确保这个错误不会再次出如今下一个 release 中。 2.这个 hotfix 程序将被标记起来以便于参考。 3.这个 hotfix 分支将被删除,而后切换到 develop 分支上去。
8、git-flow 流程图示
恭喜你,到这里你已经完成了 git-flow 的基本流程。为了更加总体的理解工做流,咱们来看看下面这张流程图: 
图片描述orm

清清楚楚,是否是和咱们上面的过程如出一辙。9、参考动力节点Java架构师班深度剖析Java底层原理,热门技术深刻探讨,前沿技术深刻解读,大项目实战重构,从0到1作架构,从全局思惟出发,带你把控大型项目中别人忽略的重要细节节点,站在巨人肩膀上学习架构师,带你领会架构师不同的视野

相关文章
相关标签/搜索