【git】(task3)git内部原理及工作流实战（更新ing）

学习总结

学习datawhale的git教程，Git-Flow模型基于Git定义5种类型的分支，各分支严格定义其指责、起始点等，从而使开发、测试、发版等过程有条不紊进行。从不同角度理解各分支：

生命周期：Master分支和Develop分支贯穿项目；其他分支均为承担特定指责的临时分支。

项目阶段：开发阶段主要涉及Feature分支、Develop分支； 发布阶段 主要涉及Release分支、Production分支、Develop分支； 紧急修复阶段 主要涉及Hotfix分支、Production分支、Develop分支。

成员关注点：开发人员关注Develop分支、Feature分支以及特殊阶段关注Hotfix、Release分支的bug修复； 测试人员 关注 Release分支、Hotfix分支的功能测试；项目经理关注Production分支、Release分支。

注：GitFlow工作流实战的学习后期补上。

新仓库会自动创建一个 .git 目录，该目录包含了几乎所有 Git 存储和操作内容。目录结构如下（后续会对 *开头 的目录详细介绍）：

├── *config 配置信息(比如本地repo是否大小写敏感, remote端repo的url, 用户名邮箱等) ├── description 无需关心（仅供GitWeb程序使用） ├── *HEAD 目前被检出的分支 ├── index 保存暂存区信息 │ │ ├── hooks/ 钩子脚本（执行Git命令时自动执行一些特定操作） ├── info/ 包含一个全局性排除文件 │ └── exclude 放置不希望被记录在 .gitignore 文件中的忽略模式 ├── logs/ 记录所有操作 ├── *objects/ 存储所有数据内容 │ ├── SHA-1/ 保存git对象的目录（三类对象commit, tree和blob） │ ├── info/ │ └── pack/ └── *refs/ 存储指向数据（分支、远程仓库和标签等）的提交对象的指针 ├── heads/ ├── remotes/ └── tags/

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

config文件（引用规范）由 git remote add origin 命令自动生成

获取远端 refs/heads/ 下的所有引用

将其写入本地的 refs/remotes/origin/ 中

更新本地的 .git/config 文件

文章目录

学习总结

五、Git 内部原理

5.1 .git的目录结构

5.2 objects目录 —— 对象存储

知识点

5.3 objects目录 —— 包文件的存储机制

5.4 refs目录 —— 引用

（1）HEAD引用

（2）远程引用

（3）标签引用

（4）stash

5.5 config文件 —— 引用规范

5.6 config文件 —— 环境变量

5.7 小练习

（1）远端分支推送

（2）邮箱配置

六、GitFlow工作流实战

6.1 深入理解Git-Flow工作流模型原理

（1）Git-Flow流程图：

（2）Git-Flow各分支的说明

（3）不同角度理解各分支

6.2 命令行演示⼀个完整的Git-Flow流程

6.2.1 初始化项目，创建Develop分支

6.2.2 模拟开发阶段过程

6.2.3 模拟Release阶段过程

6.2.4 模拟线上故障，创建Hotfix分⽀

七、时间表

Reference

五、Git 内部原理

本地仓库下有个名为 .git 的隐藏目录，这个目录下的文件结构和内容。

命令操作说明：

演示的命令是使用win10环境下的git bash工具；

‘$’ 符号所在行是演示命令；

如有内容输出，会在’$’ 符号所在行的下面输出。

5.1 .git的目录结构

创建一个名为 test 的新仓库

$ mkdir test $ cd test $ git init

1

2

3

新仓库会自动创建一个 .git 目录，该目录包含了几乎所有 Git 存储和操作内容。若想备份或复制一个版本库，只需将该目录拷贝至另一处即可。

目录结构如下（后续会对 *开头 的目录详细介绍）：

├── *config 配置信息(比如本地repo是否大小写敏感, remote端repo的url, 用户名邮箱等) ├── description 无需关心（仅供GitWeb程序使用） ├── *HEAD 目前被检出的分支 ├── index 保存暂存区信息 │ │ ├── hooks/ 钩子脚本（执行Git命令时自动执行一些特定操作） ├── info/ 包含一个全局性排除文件 │ └── exclude 放置不希望被记录在 .gitignore 文件中的忽略模式 ├── logs/ 记录所有操作 ├── *objects/ 存储所有数据内容 │ ├── SHA-1/ 保存git对象的目录（三类对象commit, tree和blob） │ ├── info/ │ └── pack/ └── *refs/ 存储指向数据（分支、远程仓库和标签等）的提交对象的指针 ├── heads/ ├── remotes/ └── tags/

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

5.2 objects目录 —— 对象存储

初始化仓库后：objects目录下只有子目录 pack 和 info ，但均为空。

这里先稍微复习下git add命令：

git add -A : 把所有变化提交到索引库，包含当前git仓库的所有目录 git add -u : 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new) git add . : 该操作与git 的版本有关： -1.x 版本：提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件 -2.x 版本：和git add -A一样，提交所有变化

1

2

3

4

5

运行以下命令，创建两个文件并提交

# 创建了 blob1 $ echo "version1" > test.txt $ git add . # 创建了 blob2 $ mkdir folder1 $ echo "file inside folder1" >folder1/file.txt $ git add . # 创建了 tree1, tree2和commit $ git commit -m "test" [master (root-commit) 67f0856] test 2 files changed, 2 insertions(+) create mode 100644 folder1/file.txt create mode 100644 test.txt

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

此时查看objects目录，会发现新增了5个子目录。

.git/objects ├── 40 │ └── fa006a9f641b977fc7b3b5accb0171993a3d31 ├── 5b │ └── dcfc19f119febc749eef9a9551bc335cb965e2 ├── 67 │ └── f0856ccd04627766ca251e5156eb391a4a4ff8 ├── 87 │ └── db2fdb5f60f9a453830eb2ec3cf50fea3782a6 ├── ac │ └── f63c316ad27e8320a23da194e61f45be040b0b ├── info └── pack

1

2

3

4

5

6

7

8

9

10

11

12

13

让我们来学习一些知识点，来解答以下疑问。

这些长串数字代表什么意思？

为什么突然多了5个子目录，分别代表什么呢？

（info和pack目录将在下一小节介绍）

知识点

1. 什么是对象？

objects目录下存储三种对象：数据对象（blob），树对象（tree）和提交对象（commit）。

5个子目录的含义如下图所示：2个blob, 2个tree和1个commit

2. Git如何存储对象？

Git会根据对象内容生成一个 SHA-1 哈希值（称为该文件的校验和）

例如：40fa006a9f641b977fc7b3b5accb0171993a3d31

截取校验和的前两个字符 => 用于命名子目录

例如：40

校验和余下的 38 个字符 => 用于文件名

例如：fa006a9f641b977fc7b3b5accb0171993a3d31

将对象内容存储在 子目录/文件名 内

3. [小拓展] 如何查看对象的存储内容

可以根据校验和，查看存储的内容及对象类型

# 查看文件类型 $ git cat-file -t 40fa006a9f641b977fc7b3b5accb0171993a3d31 blob # 查看文件内容 $ git cat-file -p 40fa006a9f641b977fc7b3b5accb0171993a3d31 file inside folder1

1

2

3

4

5

6

7

5.3 objects目录 —— 包文件的存储机制

Git默认保存文件快照，即保存每个文件每个版本的完整内容。但假设只更改了某大文件中的一个字符，保存两次全部内容是不是有点低效？

Git最初向磁盘存储对象时采用"松散"对象格式；但为了节省空间和提高效率，Git会时不时将多个对象打包成一个称为"包文件"。

当版本库中有太多的"松散"对象，或者手动执行 git gc 命令，或者向远程服务器执行推送时，Git 都会进行打包。

运行以下命令，手动打包

$ git gc Enumerating objects: 113, done. Counting objects: 100% (113/113), done. Delta compression using up to 8 threads Compressing objects: 100% (92/92), done. Writing objects: 100% (113/113), done. Total 113 (delta 15), reused 102 (delta 13), pack-reused 0

1

2

3

4

5

6

7

此时查看objects目录，会发现很多子目录不见了，而 info 和 pack 目录非空。

.git/objects ├── info │ ├── commit-graph │ └── packs └── pack ├── pack-XXX.idx └── pack-XXX.pack

1

2

3

4

5

6

7

包文件pack-XXX.pack：包含了刚才从文件系统中移除的所有对象的内容；

索引文件pack-XXX.idx：包含了包文件的偏移信息。通过索引文件可以快速定位任意一个指定对象

5.4 refs目录 —— 引用

Git把一些常用的 SHA-1 值存储在文件中，用文件名来替代，这些别名就称为引用。有三种引用类型：heads, remotes和tags。

运行以下命令，更新refs目录下的内容

# 基于当前commit创建新分支test git branch test # 基于commit打tag git tag -a v1.0 # 连接远程仓库 git remote add origin https://github.com/datawhalechina/faster-git.git git fetch # 本地修改文件，然后运行git stash echo "version2" > test.txt git stash

1

2

3

4

5

6

7

8

9

10

11

12

13

此时查看refs目录，内容如下

.git/refs ├── heads 记录本地分支的最后一次提交 │ ├── master │ └── test ├── remotes 记录远程仓库各分支的最后一次提交 │ └── origin │ └── main ├── tags │ └── v1.0 └── stash

1

2

3

4

5

6

7

8

9

10

（1）HEAD引用

HEAD引用有两种类型

（2）远程引用

存储位置： .git/refs/remotes 目录下

指代内容：远程仓库各分支的最后一次提交

注意点：用于记录远程仓库；文件是只读的，乱改就崩了

（3）标签引用

tag主要用于发布版本的管理：一个版本发布之后，我们可以为git打上 v1.0 v2.0 … 这样的标签

存储位置：.git/refs/heads 目录下

指代内容：tag可以指向任何类型（更多的是指向一个commit，赋予它一个更友好的名字）

文件内容：SHA-1值

（4）stash

存储位置：.git/refs/stash 文件

指代内容：当你想转到其他分支进行其他工作，又不想舍弃当前修改的代码时 - stash可把当前的修改暂存起来

5.5 config文件 —— 引用规范

运行以下命令，连接远程仓库

git remote add origin https://github.com/datawhalechina/faster-git.git git fetch

1

2

此时查看 .git/config 文件，会发现新添加了一段小节：

[remote "origin"] url = https://github.com/datawhalechina/faster-git.git fetch = +refs/heads/*:refs/remotes/origin/*

1

2

3

引用规范由 git remote add origin 命令自动生成

获取远端 refs/heads/ 下的所有引用

将其写入本地的 refs/remotes/origin/ 中

更新本地的 .git/config 文件

一些常用命令：

5.6 config文件 —— 环境变量

Git有三种环境变量：

1）系统变量

适用范围：对所有用户都适用

命令选项：git config --system

2）用户变量

适用范围：只适用于该用户

命令选项：git config --global

3）本地项目变量

适用范围：只对当前项目有效

命令选项：git config --local

存储位置：.git/config

一些常用命令：

5.7 小练习

（1）远端分支推送

Tom 想把自己的本地分支 feature1（当前也为 HEAD ），推送到远端分支的 feature，应当执行什么命令？

A. git push origin/feature1:feature B. git push origin feature1:feature C. git push origin HEAD:feature D. git push origin :feature

1

2

3

4

答案：B C

（2）邮箱配置

Tom工作在多个Git项目上，大部分属于公司的项目，都是使用他的工作邮箱提交。

今天他新建了一个私人项目，想使用私人邮箱进行提交。他运行什么命令更合适呢？

A. git config --system user.email "tom@私人邮箱" B. git config --global user.email "tom@私人邮箱" C. git config --local user.email "tom@私人邮箱" D. 以上选项都可以

1

2

3

4

答案：C 只对当前项目有效

六、GitFlow工作流实战

在实际项目开发工作中，常常会有自测、联调、提测、线上紧急修复等多工作环节，对应可能需要本地、内测、开发、测试、生产等多环境部署代码的需求，对应每个环节会产生不同的分支；

下面将从Git-Flow模型原理出发，通过命令行演示实际可操作⼿段并进⾏总结，最终希望Git-Flow在实际项⽬中应⽤起来，从⽽⾼效完成代码开发、版本管理等实际⼯作。

注：不同的公司或者不同的项目的GitFlow工作流模型标准也不同，具体以实际应用为准；本文提供的为常用模板，较为全面和通用

6.1 深入理解Git-Flow工作流模型原理

Git-Flow模型解决什么问题?

为了解决实际项⽬中代码开发、代码测试、bug修复、版本发布等⼀系过程列严重耦合从⽽产⽣各种问题，如冲突过度、版本混乱。

Git-Flow模型⼜是如何解决上述问题的呢?

基于Git定义5种类型的分⽀，各分⽀严格定义其指责、起⽌点等，从⽽使开发、测试、发版等过程有条不紊进⾏。

（1）Git-Flow流程图：

该流程图完整描述Git-Flow模型处理过程，当我们深⼊理解各分支，然后结合项⽬阶段与⾃身的角色（开发/测试/项目经理），就会发现每个角色在某个阶段需要关注的可能也就⼀两个分支，比如在开发阶段，开发⼈员只需关注自己的新功能分支（Feature分支）；release阶段，测试人员和开发⼈员都只需关注Release分支，只是各自的指责有所仅此差异而已；具体如下图：

（2）Git-Flow各分支的说明

（3）不同角度理解各分支

生命周期

Master分⽀和Develop分⽀贯穿项⽬；其他分⽀均为承担特定指责的临时分⽀。

项目阶段

开发阶段主要涉及Feature分⽀、Develop分⽀； 发布阶段 主要涉及Release分⽀、Production分⽀、Develop分⽀； 紧急修复阶段 主要涉及Hotfix分⽀、Production分⽀、Develop分⽀。

成员关注点

开发⼈员 关注Develop分⽀、Feature分⽀以及特殊阶段关注Hotfix、Release分⽀的bug修复； 测试⼈员 关注 Release分⽀、Hotfix分⽀的功能测试；项⽬经理 关注Production分⽀、Release分⽀。

另外要说明，项⽬阶段在时间纬度有可能重叠.⽐如:release阶段(当前版本)与下各版本的开发阶段可同时存在，因为

当前release阶段的发起同时也就意味着下⼀个release的开发阶段的开始；⼀旦线上出现bug(任何时候都可能出现)，

紧急修复阶段就可能与开发阶段、发版阶段重叠…因此，要求团队成员都要理解Git-Flow⼯作流，以及⾃身所处的项⽬阶段.

6.2 命令行演示⼀个完整的Git-Flow流程

实践⼀个从功能开发到版本发布的完整的流程：

特此说明，以下shell命令是在win10环境下，‘/e/PycharmProjects/DatawhaleChina’目录，使用git bash工具进行演示；‘$’ 符号所在行为演示命令，如有内容输出，会在‘$’ 符号所在行的下面输出。

6.2.1 初始化项目，创建Develop分支

Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina $ pwd /e/PycharmProjects/DatawhaleChina Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina $ mkdir git-demo-workflow-project Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina $ cd git-demo-workflow-project/ Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project $ touch readme.md Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project $ git init Initialized empty Git repository in E:/PycharmProjects/DatawhaleChina/git-demo-workflow-project/.git/ Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git add . Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git commit -m "init" [master (root-commit) 1ae2455] init 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 readme.md Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git checkout -b develop master Switched to a new branch 'develop'

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

6.2.2 模拟开发阶段过程

(创建新功能Feature分⽀、实现⼀个⽤户登录模块、然后合并到Develop分⽀、删除功能分⽀)

Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git checkout -b feature-login develop Switched to a new branch 'feature-login' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ touch LoginUser.html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $echo "hi, this is user html" > LoginUser.html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ cat LoginUser.html hi, this is user html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ ls LoginUser.html readme.md Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ git add . warning: LF will be replaced by CRLF in LoginUser.html. The file will have its original line endings in your working directory Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ git commit -m "feat: add LoginUser.html" [feature-login 182444e] feat: add LoginUser.html 1 file changed, 1 insertion(+) create mode 100644 LoginUser.html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ touch LoginUser.js Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ echo "hi, this is user js" > LoginUser.js Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ git add . warning: LF will be replaced by CRLF in LoginUser.js. The file will have its original line endings in your working directory Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ git commit -m "feat: add LoginUser.js" [feature-login b0d494c] feat: add LoginUser.js 1 file changed, 1 insertion(+) create mode 100644 LoginUser.js Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ git status On branch feature-login nothing to commit, working tree clean Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (feature-login) $ git checkout develop Switched to branch 'develop' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git merge --no-ff feature-login Merge made by the 'recursive' strategy. LoginUser.html | 1 + LoginUser.js | 1 + 2 files changed, 2 insertions(+) create mode 100644 LoginUser.html create mode 100644 LoginUser.js Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git branch -d feature-login Deleted branch feature-login (was b0d494c).

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

6.2.3 模拟Release阶段过程

(创建Release分⽀、进⾏bug修复、合并到Production分⽀与Develop分⽀)

Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git checkout -b release-v0.1 develop Switched to a new branch 'release-v0.1' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (release-v0.1) $ echo "bugifx LoginUser.html" >> LoginUser.html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (release-v0.1) $ git add . warning: LF will be replaced by CRLF in LoginUser.html. The file will have its original line endings in your working directory Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (release-v0.1) $ git commit -m "fix: bugfix for LoginUser.html" [release-v0.1 a37a88c] fix: bugfix for LoginUser.html 1 file changed, 1 insertion(+) Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (release-v0.1) $ git checkout master Switched to branch 'master' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git merge --no-ff release-v0.1 Merge made by the 'recursive' strategy. LoginUser.html | 2 ++ LoginUser.js | 1 + 2 files changed, 3 insertions(+) create mode 100644 LoginUser.html create mode 100644 LoginUser.js Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git tag v0.1 Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git checkout develop Switched to branch 'develop' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git merge --no-ff release-v0.1 Merge made by the 'recursive' strategy. LoginUser.html | 1 + 1 file changed, 1 insertion(+) Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git branch -d release-v0.1 Deleted branch release-v0.1 (was a37a88c).

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

6.2.4 模拟线上故障，创建Hotfix分⽀

(创建Hotfix分⽀、进⾏bug修复、合并到Production分⽀与Develop分⽀)

Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git checkout -b hotfix-v0.1.1 master Switched to a new branch 'hotfix-v0.1.1' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (hotfix-v0.1.1) $ git status On branch hotfix-v0.1.1 nothing to commit, working tree clean Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (hotfix-v0.1.1) $ echo "hotfix for LoginUser.html" >> LoginUser.html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (hotfix-v0.1.1) $ cat LoginUser.html hi, this is user html bugifx LoginUser.html hotfix for LoginUser.html Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (hotfix-v0.1.1) $ git add . warning: LF will be replaced by CRLF in LoginUser.html. The file will have its original line endings in your working directory Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (hotfix-v0.1.1) $ git commit -m "hotfix: do something for LoginUser.html" [hotfix-v0.1.1 bcb680e] hotfix: do something for LoginUser.html 1 file changed, 1 insertion(+) Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (hotfix-v0.1.1) $ git checkout master Switched to branch 'master' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git merge --no-ff hotfix-v0.1.1 Merge made by the 'recursive' strategy. LoginUser.html | 1 + 1 file changed, 1 insertion(+) Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git tag v0.1.1 Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (master) $ git checkout develop Switched to branch 'develop' Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git merge --no-ff hotfix-v0.1.1 Merge made by the 'recursive' strategy. LoginUser.html | 1 + 1 file changed, 1 insertion(+) Administrator@WIN MINGW64 /e/PycharmProjects/DatawhaleChina/git-demo-workflow-project (develop) $ git branch -d hotfix-v0.1.1 Deleted branch hotfix-v0.1.1 (was bcb680e).

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

七、时间表

Reference

datawhale notebook

git flow浅析

Git Book

廖雪峰Git教程

Git权威指南

freenode

Github-cheat-sheet

动手学Git

learn git branching

Git

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。