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

举报
野猪佩奇996 发表于 2022/05/24 00:34:23 2022/05/24
【摘要】 学习总结 学习datawhale的git教程，Git-Flow模型基于Git定义5种类型的分支，各分支严格定义其指责、起始点等，从而使开发、测试、发版等过程有条不紊进行。从不同角度理解各分支： 生...

学习总结

  • 学习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 文件
分⽀名称 作⽤ ⽣命周期 提交or合并 起⽌点
Feature分⽀ ⽤于某个功能的 临时分 ⽀、开发 阶段 可提交代码 由Develop分⽀产⽣， 最终合并到Develop 分⽀
Develop分⽀ 记录历史开发功 能 贯穿整个 项⽬ 不能提交，由F
eature分 ⽀、Bugfix分⽀、Release 分⽀、Hotfix分⽀合并代码 整个项⽬
Release分⽀ ⽤于本次Release 如⽂档、测试、 bug修复 临时分 ⽀、发版 阶段 可提交代码 由Develop分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Hotfix分⽀ ⽤于解决线上bug 临时分 ⽀、紧急 修复阶段 可提交代码 由Master分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Master（Production） 分⽀ 记录历史发布版 本 贯穿整个 项⽬ 不能提交，由Release、Hotfix分⽀合并代码 整个项⽬

文章目录

五、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 <commitId>

# 连接远程仓库
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引用有两种类型

存储位置 指代内容 文件内容
分支级别 .git/refs/heads目录下 本地分支的最后一次提交- 有多少个分支，就有多少个同名的HEAD引用 commitHash
代码库级别 .git/HEAD文件 指代当前代码所处的分支；拓展：也可指代commitHash（称为分离HEAD） 符号引用 - 例如 ref: refs/heads/master

（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 文件

一些常用命令：

命令
连接远程仓库 git remote add <远端名origin> <url>
拉取分支 git fetch <远端名origin> <远端分支名>:<本地分支名>
将远程的 main 分支拉到本地的mymaster 分支 git fetch origin main:mymaster
将本地的master分支推送到远端的topic分支 git push origin master:topic
删除远端分支topic 法1：将<src>留空
git push origin :topic
法2：Git v1.7.0新语法
git push origin --delete topic

5.6 config文件 —— 环境变量

Git有三种环境变量：

1）系统变量

  • 适用范围：对所有用户都适用
  • 命令选项：git config --system

2）用户变量

  • 适用范围：只适用于该用户
  • 命令选项：git config --global

3）本地项目变量

  • 适用范围：只对当前项目有效
  • 命令选项：git config --local
  • 存储位置：.git/config

一些常用命令：

命令
查看所有配置 git config --list
配置用户名 git config --global user.name "你的用户名"
配置邮箱 git config --global user.email "你的邮箱"

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各分支的说明

分⽀名称 作⽤ ⽣命周期 提交or合并 起⽌点
Feature分⽀ ⽤于某个功能的 临时分 ⽀、开发 阶段 可提交代码 由Develop分⽀产⽣， 最终合并到Develop 分⽀
Develop分⽀ 记录历史开发功 能 贯穿整个 项⽬ 不能提交，由F
eature分 ⽀、Bugfix分⽀、Release 分⽀、Hotfix分⽀合并代码 整个项⽬
Release分⽀ ⽤于本次Release 如⽂档、测试、 bug修复 临时分 ⽀、发版 阶段 可提交代码 由Develop分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Hotfix分⽀ ⽤于解决线上bug 临时分 ⽀、紧急 修复阶段 可提交代码 由Master分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Master（Production） 分⽀ 记录历史发布版 本 贯穿整个 项⽬ 不能提交，由Release、Hotfix分⽀合并代码 整个项⽬

（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
    •

七、时间表

Task 任务信息 时间
Task01： Git基础：第一、二章（2天） 16、17号，即周一周二
Task02： Git分支管理及工具使用：第三、四章（2天） 18、19号，即周三周四
Task03： Git内部原理及工作流实战：第五、六章（3天） 20、21、22号，即周五周六周日
Task04： Git提交规范及Github/Gitee的使用：第七、八章（3天） 23、24、25号，即周一周二周三
Task05： Git可视化工具下载和团队协作：第九、十章（3天） 26、27、28号，即周四周五周六

Reference

文章来源: andyguo.blog.csdn.net，作者：山顶夕景，版权归原作者所有，如需转载，请联系作者。

原文链接：andyguo.blog.csdn.net/article/details/124783731

【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
Git
  • 点赞
  • 收藏
  • 关注作者

评论（0）

0/1000
抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入