企业开发工具git的使用：从入门到高效团队协作

        前言：本文介绍了Git的安装、本地仓库的创建与配置，以及工作区、暂存区和版本库的区分。详细讲解了版本回退、撤销修改等操作，并深入探讨了分支管理，包括分支的创建、切换、合并、删除及冲突解决。此外，还介绍了远程操作，如远程仓库的创建与克隆，分布式版本控制的理解。最后，文章总结了系统开发环境和Git分支设计规范，强调了不同分支在开发、测试、预发布和生产环境中的作用。通过本文，您可以全面掌握Git的核心功能及其在团队协作中的应用。

目录

认识git

git安装

创建本地仓库

配置本地仓库

工作区、暂存区、版本库

版本回退

撤销修改

删除文件

分支管理

分支管理的理解

分支的创建、切换、合并

删除分支

合并冲突

bug分支

强制删除分支

远程操作

理解分布式版本控制

远程仓库创建

克隆远程仓库

​编辑

git标签管理 

多人协作1（单分支）

多人协作2（多分支）

系统开发环境

Git分支设计规范

---

本地操作

git安装

安装：

linux Centos：

sudo yum install git -y

linux Ubuntu：

sudo apt-get install git -y

 查看版本：

git --version

创建本地仓库

git并不是对任意位置的文件都能维护，我们需要创建本地仓库，如下：

创建目录gitcode：

mkdir gitcode

初始化

git init

        git init：初始化一个新的 Git 仓库。它的作用是将当前目录转换为一个 Git 仓库（或创建一个空的 Git 仓库），从而允许 Git 开始跟踪该目录下的文件变更。

初始化完成后，可以发现目录下多了一个隐藏目录.git

注意：不要手动修改.git目录里的内容。

配置本地仓库

创建完仓库后注意name 和 email必须配置，要不然后续会出现各种问题。如下：

git config user.name 用户名
git config user.name 电子邮件

查看配置结果： 

git config -l

删除配置：

git config --unser user.name 
git config --unser user.email 

让配置文件在所有仓库中都生效（加--global选项即可），如下：

git config --global user.name 用户名
git config --global user.email 电子邮件

删除配置（加--global选项）

git config --global --unser user.name 
git config --global --unser user.email 

工作区、暂存区、版本库

        如上我们在新建目录gitcode，并用git init指令初始化得到.git目录。其中gitcode目录下称为工作区，而.git目录下就是版本库。

我们在对文件进行操作是在工作区的，但并未得到git的管理，还需要把它放到.git里。

注意：不能对.git目录直接操作，会导致其内部结构错乱。应使用相关指令进行操作。

• ⼯作区：是在电脑上你要写代码或⽂件的⽬录。
• 暂存区：英⽂叫 stage 或 index。⼀般存放在 .git ⽬录下的 index ⽂件（.git/index）中，我们把暂存区有时也叫作索引（index）。
• 版本库：⼜名仓库，英⽂名 repository 。⼯作区有⼀个隐藏⽬录 .git ，它不算⼯作区，⽽是 Git 的版本库。这个版本库⾥⾯的所有⽂件都可以被 Git 管理起来，每个⽂件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

.git里面还有一个对象库，修改的工作区内容会写入对象库的一个新的git对象中。

使用指令：

• git add 文件名

把工作区的文件存储到暂存区，add后面可跟多个文件，后面跟 .（点）表示所有文件。

使用指令：

• git commit -m "xxxx"

把暂存区数据推送到版本库。其中xxxx表示你对此次修改的描述。

示例：

• git log：查看提交记录，按时间从近到远。
• git log --pretty=oneline：加选项--pretty=oneline，更简洁美观的显示，如下：

其中黄色高亮的地方为<commit-id>是 Git 提交的哈希值，用来标识文件的唯一性。

使用指令：git cat-file -p <commit-id>，用于查看 Git 对象的原始内容，其中 -p 表示 "pretty-print"（格式化输出）。

修改文件

Git追踪管理的其实是修改，而不是整个文件。

修改文件readme，添加文本hello git

使用git status查看工作状态，如下：

Git能追踪到文件readme被修改，并显示出“建议进行 git add和git commit”的字眼。

• git diff 文件名：查看暂存区和工作区的文件差异，如下：

• a：改动前
• b：改动后
• ---：改动前
• +++：改动后

指令：

• git diff HEAD -- 文件名：查看版本库和工作区的文件差异。

接下来进行add和commit，同时过程状态的变化：

版本回退

指令：git reset [--soft | --mixed | hard ] [HEAD]

• soft：只回退版本库内容。
• mixed（默认选项）：回退版本库和暂存区内容。
• hard（慎用）：回退所有区域的内容。
• HEAD：当前版，也可以填写指定的<commit-id>。

        现有两个版本的readme内容，老版本hello git，新版本hello git和hello word，下面简写为git和world：

以--hard选项为例 测试：

那么如果我们回退后，后悔了想要回到刚才的状态怎么办？

再次通过git log查<commit-id>是查不到的，如下：

我们使用指令：git reflog即可查看，如下：

        里面记录你做过的各种操作，其中黄色高亮的为<commit-id>，“缩短版”的，但依旧能对得上。如下：

版本回退过程是非常快的，为什么回退那记录？

        git版本库中主分支master指向当前版本的索引，即<commit id>，要进行版本回退，只需要改变master的指向即可。

撤销修改

        写了一半写不下去了，想重新开始写该怎么办？总不能一一删除重新写吧，我们更想要得到的是在最初开始写的状态。

        而且我们写的代码可能已经推到暂存区，或版本库了，要怎么把它撤销？

解决方法：

场景一： 

1. 手动删（不推荐）
2. git指令：git checkout -- 文件名

场景二：

1. 指令git reset HEAD（回退到版本库当前版本）再用git checkout -- 文件名。
2. 直接用git reset --hard HEAD。

场景三：

1. 指令：git reset --hard HEAD^

对于版本选项：

• commit id：指定版本
• HEAD：当前版本
• HEAD^：上一个版本
• HEAD^^：上上个版本
• ......

        注意：一旦代码推送到远程仓库就不能再撤销了，撤销的目的就是不影响远程仓库。远程仓库下文会讲解。

        撤销修改：对提交过程的撤回。即工作区->暂存区->版本库这个过程的撤回。主要是把撤销回到工作区。

删除文件

        新增文件或删除文件也是一种修改，要删除暂存区或版本库文件，只需要删除工作区文件，然后进行add和commit即可。

可简化为两步：

1. git rm 文件名：工作区，暂存区文件都被删除。
2. git commit -m “xxxx”：版本库文件删除。

分支管理

分支管理的理解

        Git 的杀手锏之⼀：分⽀。分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了 C++ ⼜学会了 JAVA！

        一个团队要开发一个项目，每个让可以延伸出一条分支，各自开发者负责自己的功能，最后进行测试再把它们进行合并在一起。

主分支master：是git最原始的分支，是整个git分支的跟。

分支的创建、切换、合并

• git branch：查找分支。

        其中我们会发现master前面有一个*，表示head指针指向master分支，也就是当前正在master分支下工作。

• head指针：在开发过程中会有很多分支，head可以指向任意分支，head指向的分支为当前正在工作的分支。即*

使用cat查看HEAD内容，如下：

创建分支

• git branch 分支名

示例：

查看.git结构，如下新增dev：

图解：

注意：创建新分支（dev分支）的“根”是当前所在的分支。新分支的内容是基于最新提交的内容。

• git checkout 分支名：切换分支

然后在dev分支下工作，最后合并到主分支。

合并分支：

• git merge 分支名

注意：不能在dev分支下合并dev分支。只能在dev分支下合并master，或在master下合并dev。

删除分支

合并后dev分支使命就结束了，最好把它删除。

• git branch -d 分支名：删除分支，注意不能在dev分支上删dev分支。

合并冲突

        如果我们在基于a分支新增分支b，然后在b上修改，同时a分支也把数据修改，此时再把两者合并时就会产生冲突。

        如上图，合并时会发生冲突，bbb和ccc只能保留一个，谁去谁留由程序员手动修改来决定。

测试：

• 指令：git checkout -b dev1

创建并同时切换到分支dev1。

        打开冲突文件file，可以发现git给我们添加<<<<<HEAD，=========，>>>>>>>dev这样的字眼，用来把两个文件新增内容区分开：

        现在需要合并，可以在master分支上删除ccc，然后进行add，commit，再进行合并。或者在dev1分支上删除bbb，然后进行add，commit，再合并。 

注意：添加的这些提示字眼也要删除。

merge冲突需要手动解决，然后重新提交合并。

• git log --graph  --abbrev-commit：图示显示提交过程

合并模式

如果我们创建分支dev2并且不产生冲突，进行合并，如下：

        Fast-forward代表“快进模式”，Fast-forword模式（即ff）不能通过图示区分是merge提交还是正常提交，如下：

建议在合并时，不使用fast-forword模式，即添加--no-ff选项，并且添加描述信息，-m选项。

• git merge --no-ff -m “xxxxx” 分支名 

分支策略

保证主分支的稳定性

多人开发

bug分支

        master出bug怎么办？master不是100%没bug。为保险起见不要直接在master主分支上直接修改。

首先使用指令：git stash

        这是一个非常有用的 Git 命令，它允许你临时保存工作目录和暂存区的修改，而无需提交这些更改。当你需要快速切换分支但又不想提交未完成的工作时，stash 就特别有用。

怎么理解stash呢？

        首先要明白，一个文件无论在任何分支下进行修改，只要没有进行add和commit，就不属于任何分支，而是属于工作区，并未涉及版本库。那么内容还不够完善我们并不想进行add或commit，又想让它属于某个分支要怎么办？使用git stash把数据保留在当前分支。

        好的，言归正传，假设我们已经基于master分支创建新的分支dev3，并且在dev3分支中进行了开发，但突然发现原来分支中master有bug，该怎么解决？

1. 保存数据：首先使用git stash指令保存当前分支的数据。
2. 修复bug：切回到master分支，在此之上创建新的分支，假设为 fix_bug，在fix_bug分支上把bug修复，然后合并回master。
3. 回到dev3上继续开发（git stash pop：恢复最近的stash），开发完成进行add和commit。
4. 因为在dev3开发期间master已经修改（bug修复），所以dev3与master合并时会出现冲突。
5. 冲突解决：为了保证master主分支的稳定性，把master合并到dev3中，在dev3中解决冲突（即删除bug代码）。
6. 冲突解决后dev3进行add和commit，再次进行合并。

关于stash的简单使用：

• git stash：把当前工作区数据保存到stash中。
• git stash list：查看stash中有那些内容。
• git stash pop：恢复最近的stash。

在解决冲突时可能会误操作，弄出bug！所以在dev3上合并。

测试后再合并到master。 

强制删除分支

        比如在写某个功能时创建了一个分支，但写到一半时（此时没有进行合并）发现，这个功能根本没必要写，把分支删除吧。

此时使用指令git branch -d无法删除，该指令只适用于合并后对分支删除，没合并会失败。

• git branch -D：强行删除。

远程操作

理解分布式版本控制

        我们⽬前所说的所有内容（⼯作区，暂存区，版本库等等），都是在本地！也就是在你的笔记本或者计算机上。⽽我们的 Git 其实是分布式版本控制系统！什么意思呢？
        可以简单理解为，我们每个⼈的电脑上都是⼀个完整的版本库，这样你⼯作的时候，就不需要联⽹了，因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本库，那多个⼈如何协作呢？⽐⽅说你在⾃⼰电脑上改了⽂件A，你的同事也在他的电脑上改了⽂件A，这时，你们俩之间只需把各⾃的修改推送给对⽅，就可以互相看到对⽅的修改了。

但是这样存在一个问题，要是自己电脑或对方电脑坏了怎么办，数据不就找不回来了嘛。

        在实际中使⽤分布式版本控制系统的时候，其实很少在两⼈之间的电脑上推送版本库的修改，因为可能你们俩不在⼀个局域⽹内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有⼀台充当“中央服务器”的电脑，但这个服务器的作⽤仅仅是⽤来⽅便“交换”⼤家的修改，没有它⼤家也⼀样⼲活，只是交换修改不⽅便⽽已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（⽐如运⽓差，硬盘坏了，上⾯的所有东西全部丢失，包括git的所有内容）

中央服务器：24小时开机。

主要流行的有国外的GitHub和国内的gitee（码云），下面我以gitee为例，讲解如何使用。

远程仓库创建

1. 首先注册或登录gitee
2. 创建仓库：

新建仓库的界面：

        创建仓库并打开，我们可以发现它比本地仓库多了三个文件，.gitfnore，README.en.md，README.md，如下：

.gitgnore文件：用来过滤不需要的文件，我们打开查看：

其中#表示注释，*.swf表示过滤所有.swf后缀的文件。

        我们可以手动对.gitgnore文件进行编辑，如果添加!a.swf表示a.swf文件不可被忽略。因为我们通常都不会把文件一个一个的推送到远程，而是批量的推送，所以有些不重要的，无关的文件就会被推送上去，有了.gitgnore文件后起到了过滤的效果。

        如果你的文件已经被 .gitignore 忽略，但仍然想强制添加到 Git 中，可以使用 git add -f（或 --force）命令。

• git check-ignore -v 文件名：检查一个文件是否已经被忽略

---

        Readme：管理者（我们）来编辑Readme文件，填写一些项目的介绍等，让读者快速了解项目的大体结构和功能，提供两个模板：README.md为中文版，README.en.md为英文版。

        issue模板：开发者（用户）在使用你的服务或使用你的代码过程中可能会发现一些bug，或者提出一些优化建议，Issue 模板 的主要作用是规范用户提交 Issue 的格式和内容，帮助项目维护者更高效地收集、分类和处理问题或建议。

        pull request模板：一个团队成员（或贡献者）在开发项目过程中，会基于你提供的主分支去创建一些子分支，进行功能开发，完成功能开发后会向你请求合并。Pull Request模板的作用是规范贡献者提交代码合并请求的格式和内容，帮助项目维护者高效审查代码、减少沟通成本，并提升协作质量。

Issues为例： 

仓库成员管理：

成员角色	权限
访客（登录用户）	对于公有仓库：创建 Issue、评论、Clone 和 Pull 仓库、打包下载代码、Fork 仓库、 Fork 仓库提交 Pull Request、下载附件
报告者	继承访客的权限。 私有仓库：不能查看代码、不能下载代码、不能 Push 、不能 Fork 、 不能提交 Pull Request、可下载附件，不能上传附件，不能删除附件
观察者	继承报告者权限 私有仓库：创建 Wiki、可以 Clone 下载代码、可以 Pull、不能 Fork
开发者	创建 Issue、评论、Clone 和 Pull 仓库、Fork 仓库、打包下载代码、创建 Pull Request、 创建分支、推送分支、删除分支、创建 Issue 标签（里程碑）、 创建 Wiki、可上传附件，可删除自己上传的附件，不能删除他人上传的附件、
管理员	创建 Issue、评论、Clone 和 Pull 仓库、打包下载代码、创建 Pull Request、 创建分支、推送分支、删除分支、创建 Issue/Pull Request 标签（里程碑）、创建 Wiki、 添加仓库成员、强制推送分支、编辑仓库属性、可上传附件，可删除自己或他人上传的附件、 不能转移/清空/删除仓库

仓库成员权限说明 - Gitee.com

克隆远程仓库

        克隆远程仓库（Clone a Remote Repository） 是指将网络上的 Git 仓库（如 Gitee、GitHub、GitLab 等平台上的项目）完整复制到本地计算机的操作。

https模式

这里介绍两种方式： 

• ssh：需要公钥加密，然后克隆。
• https：直接克隆即可

https模式：

打开xshell，创建或选择一个目录，执行以下指令：

git clone 远端仓库链接

注意：不能在本地git仓库里执行这个命令。

fetch和push 表示拥有拉权限和推权限。

        origin是一个默认的远程仓库别名（Remote Alias），它指向你克隆（git clone）的原始远程仓库地址。它是 Git 用来标识远程仓库的快捷方式，方便后续操作（如推送、拉取代码等）。当你执行 git clone 时，Git 会自动将远程仓库地址命名为 origin。

ssh模式

和https同样的方法，进行克隆：

如下，我们是无法进行克隆的，因为没有公钥。 

需要把本地服务器公钥放到git上进行管理。

打开gitee设置->打开ssh公钥->设置公钥。

        获取公钥：打开本地主目录（如linux的root目录下）->在文件.ssh下看有没有id_rsa（私钥）和id_rsa.pub（公钥），如果没有先使用指令生成公钥，如下：

• ssh-keygen -t rsa -C "电子邮件"

执行命令后一直回车即可。

注意：电子邮件要和gitee的保持一致。看邮箱：打开gitee设置->邮箱管理。

        然后复制id_rsa.pub文件的内容，粘贴到gitee公钥配置的位置，点击确定生成公钥。完成以上操作后再进行克隆。

多人协作时可配置多个公钥。

ssh模式的好处：

• SSH 使用密钥对认证（公钥+私钥），只要本地私钥配置正确且添加到远程仓库（如 GitHub、GitLab），克隆或推送时无需重复输入账号密码。

• HTTPS 克隆可能需要每次输入密码（除非配置凭据缓存或使用 Personal Access Token）。

• SSH 通过非对称加密通信，防止中间人攻击（如果服务器指纹受信任）。

• HTTPS 虽然也加密，但若使用密码认证且未配置二次验证，可能存在风险（例如密钥泄露）。

远程推送操作

把本地版本库的文件推送到远端：

• git push origin <本地分支> : <远端分支>

把远端的数据拉取到本地：

• git pull origin <远端分支> : <本地分支>

注1：要成功推送，必须保证本地的数据要新于远端的数据，如果不够新，则先使用git pull拉取。其次就算没有最新代码也pull一下，是一个好习惯。

注2：配置 user.name和user.email和远端一样。

注3：pull不仅拉取，还顺便进行了合并。

推拉操作

配置命令别名

• git config --global alias.别名 原名

--global选项：全局生效。

所有git命令都能配置别名。

例如：

git标签管理 

• 给最新提交版本打标签：git tag 标签名
• 给指定版本打标签：git tag 标签名 <commit-id>
• 看有那些标签：git tag
• 查看指定标签的详细信息：git show 标签名
• 给标签加描述：git tag 标签名 -m “xxxx” [<commit-id>]
• 删除标签：git tag -d 标签名

推送标签

• 推送指定标签：git push origin 标签名
• 推送所有标签：git push origin --tags

删除标签有两种方法：1.本地删除然后推送到远端。2.远端删除。

以方法1为例，假设要删除标签v1.0,：

1.本地删除：

• git tag -d v1.0

2.删除结果推送到远端

• git push origin : v1.0

多人协作1（单分支）

目标：master分支下file.txt文件新增代码"aaa", "bbb"

实现：开发者1新增"aaa"，开发者2新增"bbb"

条件在同一分钟下协作完成。

一、远端操作：新建一个分支，名为dev

二、本地操作：

开发者1：

1. 克隆远程仓库。
2. 创建本地分支dev。
3. vim创建并打开文件file.txt，添加"aaa"。
4. 进行add，commit和push，推送到远程。

第2部，在创建本地分支dev时可以顺便与远程的dev分支做连接。使用指令：git checkout -b dev origin/dev

• checkout：创建分支
• -b：切换到创建的分支
• dev：分支名
• origin/dev：与远程分支dev建立连接  

        建立连接有什么用呢？建立连接后推送时直接使用git push即可，拉取时直接使用git pull，而不需要使用指令git push origin <本地分支> : <远端分支>。

刚才是创建分支的同时建立连接，如果创建完分支后才想起来要建立连接怎么办呢？

使用指令：git branch --set-upstream-to=origin/dev dev

git branch -a：查看所有分支情况，即本地分支和远程分支。如下：

如果没有显示对应的远程分支，使用git pull指令会把远程分支同步到本地。

git branch -vv：查看本地分支与远程分支的连接情况。如下：

开发者2：

1. 克隆远程仓库。
2. 创建本地分支dev。
3. vim创建并打开文件file.txt，添"bbb"。
4. 进行add，commit和push，推送到远程。

对于第二部的细节与以上所讲相同。

        对于第四部，如果开发者1先推送了file.txt，开发者2再推送就会发生冲突，即与远端的file.txt发生冲突。如何处理冲突？

        把远端的文件pull拉取下来，然后修改file.txt，让本地的file.txt同时有aaa和bbb。然后重头开始执行第四部。

三、最后把远程dev合并到master，两种方法：

方法1：

申请并填写合并申请单：

对于管理者，进行代码测试和审核，然后合并：

方法二：在本地合并后推送到远程的master分支（不推荐）。

最后dev分支用完就可以删了。

多人协作2（多分支）

目标：远端master分支下新增function1和function2。

实现：开发者1新增function1，开发者2新增function2。

条件：在不同分支下协作完成。

该协作方式更为灵活，有各自的分支实现对应的功能。

一、远程操作：在远程创建dev1和dev2分支分别给开发者1和开发者2使用。

二、本地操作：

开发者1：

1. 如果没有克隆仓库先克隆。
2. 创建自己的本地dev1分支并与远程dev1分支连接。
3. 创建并编辑文件function1。
4. 进行add，commit和push

开发者2：

1. 如果没有克隆仓库先克隆。
2. 创建自己的本地dev2分支并与远程dev2分支连接。
3. 创建并编辑文件function2。
4. 进行add，commit和push

        注意：无论是开发者1还是开发者2在push之前都建议执行指令git pull，保证本地仓储数据和远程仓库同步。

三、远程操作：申请合并单把dev1和dev2合并到master主分支。

如果合并过程有冲突，我们在的次分支下解决冲突，再合并到master分支，如下：

系统开发环境

1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。开发人员不能直接把代码部署到用户能访问到的服务器，而是有自己的服务器。即环境隔离。

Git分支设计规范

Git分支有很多模型，其中Git Flow模型被广泛使用，如下：

分⽀	名称	适⽤环境
master	主分⽀	⽣产环境
release	预发布分⽀	预发布/测试环境
develop	开发分⽀	开发环境
feature	需求开发分⽀	本地
hotfix	紧急修复分⽀	本地

注：以上表格中的分⽀和环境的搭配仅是常⽤的⼀种，可视情况⽽定不同的策略。

图示：

• master分⽀：master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并release 分⽀得到。主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码。 产品的功能全部实现后，最终在master分⽀对外发布，另外所有在master分⽀的推送应该打标签（tag）做记录，⽅便追溯。master分⽀不可删除。
• release分⽀：release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基于 develop 分⽀创建。可以部署到测试或预发布集群。命名以 release/ 开头，建议的命名规则: release/version_publishtime 。release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码为基准进⾏提测。如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。release 分⽀属于临时分⽀，产品上线后可选删除。
• develop分⽀：develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）。
• feature 分⽀：feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分⽀。命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。⼀旦该需求发布上线，便将其删除。
• hotfix 分⽀：hotfix  分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便将其删除。

非常感谢您能耐心读完这篇文章。倘若您从中有所收获，还望多多支持呀！