【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
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小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章