Datawhale学习git--第三节

Git内部原理

本地仓库下有个名为 .git 的隐藏目录，本章将带你了解这个目录下的文件结构和内容，从底层出发带你了解Git内部是如何运作的。

在Git中，.git目录是Git版本库的核心，包含了几乎所有Git的存储和操作内容。下面是对.git目录结构的简要解释：

1. config： 存储配置信息，如本地repo是否大小写敏感、remote端repo的url、用户名邮箱等。

2. description： 无需关心，仅供GitWeb程序使用。

3. HEAD： 记录当前被检出的分支。

4. index： 保存暂存区信息。

5. hooks/： 包含钩子脚本，用于在执行Git命令时自动执行一些特定操作。

6. info/： 包含一个全局性排除文件（exclude），用于放置不希望被记录在 .gitignore 文件中的忽略模式。

7. logs/： 记录所有操作的日志。

8. objects/： 存储所有数据内容，包括三种对象：commit、tree和blob。对象存储结构按SHA-1哈希值组织，子目录用于提高对象查找效率。

     知识点

     1. 什么是对象？

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

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

     2. Git如何存储对象？

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

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

   # 查看文件类型 $ git cat-file -t 40fa006a9f641b977fc7b3b5accb0171993a3d31 blob

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

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

   2. 例如：40fa006a9f641b977fc7b3b5accb0171993a3d31

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

   4. 例如：40

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

   6. 例如：fa006a9f641b977fc7b3b5accb0171993a3d31

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

9. refs/： 存储指向数据（分支、远程仓库和标签等）的提交对象的指针。

这个目录结构在初始化仓库后会被创建。在创建和提交文件后，objects目录下的子目录数量会增加，每个子目录对应一个对象类型（blob、tree或commit）。

此外，Git还会进行对象的打包，将多个对象打包成一个包文件（pack），以节省空间和提高效率。这些操作可以通过手动执行git gc命令触发。

一些常用命令：

	命令
连接远程仓库	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

总体而言，.git目录是Git版本库的核心，负责存储和管理版本控制的所有信息。

GitFlow工作流实战

1. 分支命名与用途：

   1. Master分支： 主分支，代表生产环境的稳定版本。

   2. Develop分支： 开发分支，用于整合各个功能分支的最新代码。

   3. Feature分支： 功能分支，用于开发新功能。

   4. Release分支： 发布分支，用于准备发布新版本。

   5. Production分支： 生产分支，代表当前正处于生产环境的版本。

   6. Hotfix分支： 紧急修复分支，用于修复生产环境中的紧急问题。

2. 项目阶段与分支关系：

   1. 生命周期： Master和Develop分支贯穿整个项目生命周期。

   2. 项目阶段：

      • 开发阶段： Feature和Develop分支主要参与。

      • 发布阶段： Release、Production和Develop分支参与。

      • 紧急修复阶段： Hotfix、Production和Develop分支参与。

3. 成员关注点：

   1. 开发人员： 关注Develop、Feature、Hotfix和Release分支，特别关注bug修复。

   2. 测试人员： 关注Release和Hotfix分支，进行功能测试。

   3. 项目经理： 关注Production和Release分支。

4. 时间维度重叠：

   1. 项目阶段在时间维度上可能重叠，例如Release阶段与下个版本的开发阶段可以同时存在。

5. Git-Flow演示过程：

   1. 初始化项目： 创建项目、初始化Git仓库。

   2. 功能开发阶段： 创建Feature分支，实现功能，合并到Develop分支。

   3. 版本发布阶段： 创建Release分支，进行bug修复，合并到Master和Develop分支，打标签。

   4. 紧急修复阶段： 创建Hotfix分支，修复bug，合并到Master和Develop分支。

重难点

1. 分支的命名与用途：

   1. Master和Develop分支： 这两个分支是整个工作流的核心。Master分支代表生产环境，Develop分支用于整合各个功能分支的最新代码。团队成员需要理解它们的用途和关系。

2. Feature分支的创建与合并：

   1. Feature分支的创建： 在开发新功能时，团队通过创建Feature分支，避免直接在Develop分支上进行开发，保持主分支的稳定性。

   2. Feature分支的合并： 完成新功能的开发后，需要将Feature分支合并回Develop分支。这一过程涉及到分支的切换、代码的合并和可能的冲突解决。

3. Release分支的创建与版本发布：

   1. Release分支的创建： 当开发完成，需要进行版本发布时，创建Release分支。这一阶段通常包括bug修复、版本号的更新等操作。

   2. Release分支的合并与标签打上： Release分支在经过测试后，需要合并回Master和Develop分支，并为该版本打上标签。这标志着一个稳定版本的发布。

4. Hotfix分支的创建与紧急修复：

   1. Hotfix分支的创建： 当生产环境出现紧急问题时，需要创建Hotfix分支。这一过程是突发情况下的迅速响应，需要在Master分支上修复问题。

   2. Hotfix分支的合并： 修复后，Hotfix分支需要合并回Master和Develop分支。

5. 分支的删除：

   1. 分支的删除操作： 在合并完成后，不再需要的Feature、Release、Hotfix分支可以被删除。这一步骤的执行需要注意确保已经完成了合并和测试。

6. 分支管理与团队协作：

   1. 分支管理的目的： Git-Flow工作流的目的是使团队能够协作开发，保持主分支的稳定性，同时能够在不同阶段进行版本控制和发布。

   2. 团队协作的重要性： 团队成员需要相互协作，确保每个分支的合并和操作都在整个团队的认知和计划之下进行。