提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
基于Git的版本控制【系统学习】
一、预备知识
1.1 版本控制系统
1.11 什么是版本控制系统
以游戏为例，玩家可以在游戏的某些位置存档，之后可以在不同存档之间切换，存档与切换就是版本控制系统的常用功能。
管理一些文件时，若内容发生了变更，我们就可以使用版本控制系统记录下这些文件的当前内容，即当前“版本”信息，之后可以使用版本控制系统进行版本切换等功能。
1.12 为什么需要版本控制系统
就个人而言，如果你不小心误删或修改了某个文件或某个文件的某些内容，当你后悔时，版本控制系统可以帮你找回这些文件和内容。
就软件开发而言，一个项目往往需要多人协作完成，有些文件是多人共享的，当其他人修改了共享的文件时，可能会给你带来一些麻烦和困惑。
版本控制系统清楚地记录了文件在何时创建、以及每一次修改的详细信息（何人在何时做了何种修改）。既提供了回退版本的后悔药，也可以避免甩锅的麻烦（bug谁写的一清二楚）。
1.13 版本控制系统的分类
版本控制系统可以分为两类：集中式与分布式
集中式版本控制系统：由一台专用的服务器提供版本控制服务，需要连接到该服务器才能使用版本控制服务，如果断网或者运行版本控制系统的服务器崩溃，将无法使用版本控制服务。CVS和SVN属于集中式的版本控制系统。
分布式版本控制系统：分布时版本控制系统支持在本地进行临时的版本控制，当断网时或者无法连接服务器时也可以使用，待网络恢复或服务器可用时再进行同步即可。显然，分布式的版本控制系统更好用。Git属于分布式的版本控制系统。
1.2 Git简介
1.2.1 Git的优缺点
优点：免费开源，是分布式的版本控制系统，基于“快照”的版本控制的速度快、生成的文件体积小
缺点：易学难精，20%的指令可以完成80%的工作，但是剩余的80%的指令需要花大量时间才能掌握
1.2.2 Git，GitHup，Gitee，GitLab
Git：是进行版本管理的工具，一款开源免费的分布式版本控制系统
GitHub：是国外开发的面向全球的Git服务器，作为远程仓库使用
Gitee：是国内开发的面向国内的Git服务器，作为远程仓库使用
Gitlab：是一套基于Git的私服地址，用于搭建企业自己的代码仓库/远程仓库
1.2.3 安装Git
官网下载：https://git-scm.com/downloads
可以顺便安装上图形界面工具（GUI：Graphic User Interface）
1.2.4 配置Git
必须配置的是用户信息（其他的有需要再了解），包括用户名和邮箱，命令如下：
// 1. 配置用户信息（当某个项目不想用全局用户时，可以使用local来配置该项目专用的用户信息）
git config --global|local user.name "Java Potato"
git config --global|local user.email "[email protected]"
// 2. 查看配置的用户信息
git config --list
1.3 终端机环境下的常用命令行
以下为Windows/macOS/Linux的常用命令行，其中macOS和Linux的这些命令是一样的。
| 常用功能 | Windows | macOS/Linux | |
| 目录操作 | |||
| 切换目录 | cd | cd | |
| 查看当前目录 | cd | pwd | |
| 创建目录 | mkdir | mkdir | |
| 删除目录 | rmdir | rmdir | |
| 修改目录名/移动目录 | move | mv | |
| 文件操作 | |||
| 创建文件 | 无 | touch | |
| 删除文件 | del | rm | |
| 修改文件名/移动文件 | move | mv | |
| 复制文件 | copy | cp | |
| 其他常见操作 | |||
| 清空命令行界面 | cls | clear | |
| 列出当前目录下的文件列表 | dir | ls | |
1.4 Vim编辑器的使用
Vim是Linux中的一款文本编辑器，也是Git的默认编辑器，它有两种主要模式：Normal和Insert。
Normal模式：Vim打开文件时的初始模式，该模式下不能输入文本，一般用于查看（移动光标）和复制操作。该模式还支持文件的存储和退出、进入Inset模式。
文件的存储和退出：在Normal模式下，通过输入“:w”来存储文件，通过输入“:q”来退出Vim，通过输入“:wq”来存储文件并退出Vim。
Insert模式：进入Insert模式后可以编辑文件的内容。在Normal模式下输入“i”或“a”或“o”可以进Insert模式。其中“i”表示insert，会将输入内容写入当前光标处；“a”表示append，会将输入内容写入文件尾部；“o”会将输入内容在新建的一行写入。在Insert模式模式下，通过“Esc”来切换到Normal模式。
二、Git使用初级：将文件交由Git管理
2.1 工作区、暂存区与本地仓库
各区关系和相关指令如图所示（图来源于菜鸟教程）：
workspace：工作区，也称工作目录，即Git仓库所在的磁盘目录，工作目录中不一定所有文件都会交给Git管理（如一些敏感数据，一般是不会交给Git管理的）
staging area：暂存区/缓存区，交由Git管理的文件中，发生了修改且尚未commit的文件都会暂存在这里
local repository：版本库或本地仓库，暂存区中的文件使用commit提交后就会被移动到本地仓库
remote repository：远程仓库，需要和本地仓库关联后使用
2.2 常用指令
| 功能 | 命令 | 说明 |
|---|---|---|
| 创建本地仓库 | init | 使用Git进行版本管理的第一步是创建本地仓库，会创建一个.git文件，版本控制所需文件都在里面 |
| 将文件交给Git管理 | add | 将文件添加到暂存区 |
| 删除文件 | rm | 将文件从暂存区和工作区移除，分缓存删除和物理删除 |
| 移动/重命名文件 | mv | 和linux中的mv命令一致 |
| 查看仓库状态 | status | 可以看到哪些文件还没交给Git管理，交给Git管理的文件中哪些发生了修改 |
| 进行一次提交 | commit | 将暂存区中的文件提交到存储库中 |
add指令：git add .可以把当前目录下的所有文件都交由Git管理，但不建议如此使用！需要什么文件，添加什么文件。
rm指令：默认采用的是物理删除，即直接从暂存区和工作区都删除。可以加上--cached参数来进行缓存删除，此时会将文件从暂存区移动到工作区，即不再由Git管理。如果文件在删除之前修改过且尚未commit，则必须要用强制删除选项-f。
mv指令：Git提供的mv指令，可以用来“一段式”删除文件，若先用linux的mv命令删除文件，则还需要先add再commit才能从仓库中删除，相对来说比较麻烦（rm命令同理）。当然，mv命令也能用来给为文件重命名。
commit指令：提交时需要提供本次提交的描述信息，格式如git commit [file1] [file2] ... -m [message]，不然会跳出Vim界面让你填写提交信息。提交信息应当简介明了，告知发生了何种修改。如果不使用file参数指定要提交的文件，则会提交缓存区中的所有文件。如果嫌两段式提交（见后）很麻烦，想一步完成，可以使用-am分一步完成（add和m的结合）。
2.3 两段式提交
两段式提交的意义：减少commit的次数，从而减少版本的数量
commit是Git进行版本管理的基本单位，每次commit都会生成一个对应的版本。如果按一段式提交，那么会在每次更新时都创建一个版本，造成版本数量爆炸。两段式提交，可以先将修改的内容放入到暂存区，等到合适的时机再一起批量提交，只生成一个版本，从而大大减少了总的版本数量。
提交的时机：没有严格的规定，可以在完成一个阶段性工作后提交，可以在吃午饭、晚饭后提交，也可以每天下班时提交
2.4 status指令的结果说明
说明一：status指令只会显示没有交给Git管理的文件和Git管理的文件中存在更新（增删改）的文件。在Git管理的文件中，不存更新的文件不会显示
说明二：对于新增的空文件夹，Git是“无法感知”的。如果需要Git来管理这个新建的文件夹，则需要其不为空。简单的做法就是随便在该文件夹下新建一个文件，惯例是新建一个名为“.keep”或“.gitkeep”文件
说明三：文件名不重要。在Git中，版本信息是基于文件内容的，修改文件名并不算文件内容发生修改，修改文件名后仍属于最新的那个commit记录
情形一：没有尚未交给Git管理的文件，且在Git管理的文件中，没有存在更新的文件
情形二：存在没有交给Git管理的文件时，它们会显示在Untracked files中
情形三：交个Git管理文件中，若存在有更新的文件，且该版本还没有add，则会出现在Changes not staged for commited中，会标注变更类型（如modified，deleted等），此部分的文件名会显示为红色
情形四：交个Git管理文件中，若存在有更新的文件（包括新交给Git管理的文件），且该版本已经add但尚未commit，则会显示在Changes to be commited中，会标注变更类型，此部分的文件名会显示为绿色
2.5 仅将工作目录中的部分文件交给Git管理（忽略某些文件）
- 在项目目录中新建一个“.gitignore”文件（可能已经存在，不存在则新建）
- 在“.gitignore”文件中配置需要忽略的文件（一行对应一个需要忽略的文件名）
说明一：对于已经交给Git管理的文件，配置忽略该文件时，会发现忽略失效，此时需要再git rm --cached filename才能将其忽略
说明二：被忽略的文件不会被Git感知，所以也不会出现在Untracked Files中
说明三：已经被忽略的文件可以被强制交给Git管理，命令为git add -f filename
“.gitignore”文件
对于一些编译过程生成的临时文件，以及一些较为机密的文件（如存储有账号密码的配置文件），我们并不希望它们被Git管理，前者没有价值，后者要防止泄漏。这种时候，我们在项目目录中新建一个“.gitignore”文件，配置需要忽略的文件即可（每一行对应一个需要被忽略的文件）。
对于存在于“.gitignore”文件中的文件，且是在“.gitignore”文件之前创建的文件，是不会被忽略的，导致忽略失效。
对于存在于“.gitignore”文件中的文件，且是在“.gitignore”文件之后创建的文件，Git是“感知不到”这些文件的存在的，如果我们突然需要让Git感知这些文件，又不想变动“.gitignore”文件，那么可以使用“git add -f 文件名称”的方式来让Git管理这些文件。
2.6 仅将文件内容交由给Git管理
添加文件时，使用git add -p filename，此时会询问是否把整个区域添加到暂存区，选择“y”时会将整个文件添加到暂存区，选择“e”则会出现编辑器，我们可以删除那些不想交给Git管理的内容。
三、Git使用中级：管理commit记录
3.1 查看commit记录
方式一：使用git log命令可以查看所有的commit记录，每个记录都包含四个信息：版本号、作者、日期、描述信息。这些commit记录会从上到下排序，最上面的是最近提交的。下图展示了log示例：
关于版本号：是commit记录的唯一标识，基于文件的内容使用SHA-1算法计算得到
方式二：使用可选参数--oneline和--graph来查看精简版的commit记录，此时只会显示版本号和描述信息，且版本号只会显示前几位（一般6~8位，如果会发生冲突，就会显示更多位数）
方式三：如果要查询特定的commit记录（一般使用--oneline参数来先查询精简的commit记录信息）
| 功能 | 命令 |
|---|---|
根据author信息查询（多个用户名要用\|隔开） | git log --oneline --auther="Java Potato\|Tom" |
| 根据描述信息查询 | git log --oneline --grep="string" |
| 根据文件名查询（精简） | git log --oneline “filename” |
| 根据文件名查询（详细：包括具体更新的内容，+表示增，-表示删除） | git log --p “filename” |
| 根据文件名查询（查看哪一行由谁最后修改） | git blame “filename” |
| 根据时间范围查询（默认位当日） | git log --oneline --since="9am" --util=“12pm” |
| 根据日期范围查询（可以配合时间使用） | git log --oneline --after“2024-04” --before“2024-05” |
| 以行为单位查看某文件的commit记录（可指定行范围） | git blame -L start,end |
方式四：使用git relog或git log -g可以查看版本的变更记录，再撤销或回退后，还能借助该指令找到“丢失”的commit记录，以撤销前面的撤销或回退操作
3.2 “修复”commit记录
使用--amend参数，支持两种修复操作
- 修改最新commit记录的描述信息：
git commit --amend -m "..."（会生成一个全新的commit来覆盖原commit，尽管文件内容并未改变） - 将最新修改文件并入最新的commit记录（以减少commit次数）：
git commit --amend --no-edit
可以使用Rebase命令来修改更早的commit记录，但尽量不要这么做，避免给其他人带来困扰。
3.3 常见的恢复操作
| 功能 | 命令 | 说明 |
|---|---|---|
| 拆掉重做 | git reset HEAD <file> | 撤掉一个commit记录，将暂存区的文件放回到工作区，已经做了的修改不会丢失，存储在工作区中 |
| 抵消修改 | git revert HEAD <file> | 新增一个commit记录，它执行的是与指定commit记录中反转的操作 |
| 撤销修改 | git checkout --<file> | 将（已未add和未commit的）文件恢复到上次commit时的状态，已作的修改会丢失（物理覆盖） |
| 撤销修改 | git restore --<file> | 是新版Git中提供的指令，和checkout指令撤销修改的功能一致 |
补充1：撤销重做和恢复版本都可以到指定版本，此时可以使用相对版本号和绝对版本号，如Head^^^是Head之前的第3个版本，Head~6是Head之前第的6个版本。
补充2：git reset有三个可选的参数，差别如下表所示
| 模式 | 工作目录 | 暂存区 | 说明 |
|---|---|---|---|
| –mixed（默认） | 不变 | 被删除 | 放回工作目录 |
| –soft | 不变 | 不变 | 放回暂存区 |
| –hard | 被删除 | 被删除 | 物理删除 |
四、分支的使用
4.1 什么是分支
为了便于理解，我们可以将分支看作从某个版本分离出来的一个副本，不同分支相互独立。
实际上，分支实只是指向更改快照的指针。Commit记录之间会形成版本链，从版本A提交commit后形成的版本B会指向版本A，该单向边表示的commit记录之间的“来源关系”。当创建一个分支时，分支指针会指向最新的那个Commit记录。之后，在该分支上可以进行独立的Commit，分支指针会指向该分支上最新的那个Commit。
4.2 为什么要使用分支
- 并行开发：多个开发者在各自的分支上进行开发，相互独立，可以避免开发过程中的代码冲突（合并时再处理冲突）
- 版本控制：分支提供了一个便捷的方式来管理不同的代码版本。在每个分支上，开发人员可以进行不同的实验和修改，而保留了主分支的稳定性。这意味着即使发生了错误或不必要的更改，可以通过切换到其他分支恢复到之前的状态。
- 功能开发：分支可以用来开发新的功能或修复现有功能的问题。通过在一个分支上添加新的功能，可以保持主分支的稳定性，直到新功能完全测试通过并准备好合并到主分支。这样可以避免在开发新功能期间破坏已有功能。
- 合并和冲突解决：当多个开发者在同一时间段内对相同文件进行修改时，可能会发生代码冲突。Git的分支机制使得合并和冲突解决变得相对简单。开发人员可以在不同的分支上进行独立的工作，并在需要时将更改合并到主分支中。当出现冲突时，Git提供了工具来帮助开发人员解决冲突并进行合并。
- 代码审查：分支还可用于进行代码审查。开发人员可以创建一个分支来添加或修改代码，并将其发送给其他开发者进行审查。审查人员可以在分支上进行注释、建议修改，并提供反馈意见。这样可以确保代码质量，并提高团队合作的效率。
4.3 管理分支的常用指令
| 功能 | 命令 | 说明 |
|---|---|---|
| 查看分支 | git branch | 默认会有一个名为master的分支，*符号标记的分支为当前所在的分支 |
| 创建分支 | git branch cat | 创建一个名为cat的新分支并指向当前分支最新的Commit记录上 |
| 创建分支 | git branch cat xxxx | 创建cat的新分支并指向SAH1为xxxx的Commit记录上 |
| 更改分支名称 | git branch -m cat dog | 将cat分支的名字改为dog |
| 删除分支 | git branch -d cat | 将cat分支删除 |
| 切换分支 | git checkout cat | 切换到cat分支 |
| 合并分支 | git merge cat | 将cat分支合并到当前分支（本质是合并Commit记录） |
4.4 合并分支的两种方式
4.4.1 使用merge合并分支（两种情形）
情形一：被合并分支指向的commit记录与当前分支指向的commit记录之间存在通路时，会采用快转模式（Fast Forward），此时当前分支会指向被合并分支所指向的那个commit记录
情形二：被合并分支指向的commit记录与当前分支指向的commit记录之间不存在通路时，会产生一个新的Commit记录，它会指向合并的那两个分支所指向的Commit记录，之后当前分支再指向这个新的Commit记录
补充：分支合并并不会让两个分支变为一个分支，而是将某个分支的内容合并到当前分支中去，最后还是两个分支
4.4.2 使用ReBase来合并分支（了解）
使用git rebase cat，会使用cat分支指向的Commit记录为基准（base）来重构自己的Commit记录。重构后，当前分支中的第一个Commit记录会指向cat分支指向的Commit记录。
以这种方式来合并分支，不会出现新建Commit记录的情况，但是会重构当前分支已有的Commit记录，可能会给人带来困扰，故不建议使用。
重构Commit记录不会删除原来旧的Commit记录，但这些旧的Commit记录会逐渐边缘化，直到触发资源回收被删除。
4.5 解决冲突
4.5.1 什么是冲突
当合并的两个分支修改了相同的文件时，就会发生冲突。此时需要我们解决冲突，是保留当前分支中的版本，还是保留被合并分支中的版本，或者采用其他方式处理。
发生冲突时会有如下界面，如图，提示file.txt中存在冲突
补充：使用git status可以查看合并冲突的文件，没有冲突的文件会放在暂存区，而冲突的文件会显示在Unmerged Paths部分。
4.5.2 冲突查看与解决
合并时若发生冲突，则会提示冲突文件，并在文件中提示冲突情况。使用Vim可以打开文件并修改以解决冲突。如下，<<<<<<< HEAD和=======之间的内容为当前分支中该文件的冲突数据，而=======和>>>>>>> cat之间的内容为cat分支中该文件的冲突数据。
解决冲突时，直接修改文件内容即可，如将cat分支中的数据删除，在当前分支中的数据保留，再删除<<<<<<< HEAD、=======和>>>>>>> cat这些标记，最后再add并commit即可完成合并。
特殊情形：如果是非文本文件的内容发生了冲突，如二进制文件、图文件等，此时通过修改内容来解决冲突是不实际的。我们可以选择一个冲突版本，使用git checkout --ours xxx.jpg表示使用当前分支的版本，使用git checkout --their xxx.jpg表示使用被合并分支的版本，之后再add并commit即可完成合并。
4.6 标签的使用
4.6.1 标签和分支的异同
标签和分支类似，都指向某个commit记录的指针，不同的是，分支对应的指针会随着commit而移动，始终指向最新的那个commit记录，而标签不会移动。此外，两者的作用也不同，标签主要用于标记一个里程碑版本，而分支主要用于并行开发。
分支信息存储在refs下的heads中，而标签信息存储在refs下的tags中。
HEAD在Git中既不是一个分支也不是一个标签，它是一个特殊的指针，其指向当前所在的提交（commit）。确切地说，HEAD是代表你当前工作目录和索引所关联的分支的最后一次提交。
4.6.2 创建标签
标签分为轻量级标签和有附注的标签，后者多包含一些信息（打标签的人、时间、标签描述信息）。
打轻量级标签：git tag tag_name commitId
打有附注的标签：git tag tag_name commitId -a -m 'tag description'
4.6.4 查看标签
git show tag_name
五、修改历史commit记录
使用git rebase -i xxxx可以进入互动模式，常在修改历史commit记录时使用。指令参数-i表示的是进入互动模式，会展示从当前版本到指定的xxxx版本之前的所有commit记录，显示格式如下。其中pick表示不做修改，接着的是commit的版本号和描述信息。注意，这里显示顺序和git log不同，最近的commit记录在下面。
5.1 修改历史commit记录的描述信息
- 使用
git rebase -i xxxx进入互动模式 - 找到目标commit记录的对应行，将pick修改为reword，然后保存离开
- 会弹出vim界面，填写新的描述信息，保存离开即可（如果要一次修改多个commit记录的描述信息，则会相继弹出来修改）
虽然是修改描述信息，并没有修改文件内容，但是还是会生成新的commit记录
5.2 合并某些commit记录
- 使用
git rebase -i xxxx进入互动模式 - 找到需要被合并的commit记录，将pick修改为squash，然后保存离开
- 会弹出vim界面，填写描述信息，保存离开即可
pick修改为squash后，对应记录会和其之前的commit记录合并，并且会生成一个新的commit记录，需要填写新commit记录的描述信息（使用rebase时都会生成新的commit记录）
5.3 将一个commit记录拆分为多个
- 使用
git rebase -i xxxx进入互动模式 - 找到需要拆分的commit记录，将pick修改为edit，然后保存离开
- 使用命令
git reset将该commit记录拆掉重做 - 选择文件进行分批次add和commit即可
- 最后，使用命令
git rebase --continue完成rebase操作
5.4 在某个特定的commit记录之后添加新的commit记录
- 使用
git rebase -i xxxx进入互动模式 - 找到这个特定的commit记录，将pick修改为edit，然后保存离开
- 进行add和commit操作（可以有多个）
- 最后，使用命令
git rebase --continue完成rebase操作
5.5 调整已有commit记录的顺序
- 使用
git rebase -i xxxx进入互动模式 - 调整commit记录的顺序，然后保存离开
5.6 删除某个已有的commit记录
- 使用
git rebase -i xxxx进入互动模式 - 找打需要删除的commit记录，将pick修改为drop，然后保存离开
（该commit提交的修改会重新进入工作区）
六、使用远程仓库
6.1 关联远程仓库
使用远程仓库的第一步是将本地仓库和远程仓库关联起来，此时需要使用如下命令。其中，origin为远程仓库的别名，可以随便起，address为远程仓库的地址。
git remote add origin address
6.2 从本地仓库Push数据到远程仓库
我们可以使用git push origin master，将当前分支推动到origin（远程仓库）的master分支上。如果远程仓库中没有master分支，则会先创建一个master分支。
我们还可以使用git push -u origin master来推送，此时会将origin中的master分支作为当前分支的上游（upstream）。此后可以使用git push来推送，会自动将当前分支推动到远程仓库中对应的上游分支。
补充1：git push origin master:cat，将当前分支推动到origin的master分支，若不存在master分支，则会创建一个名为cat的分支，然后将当前分支推送到cat分支。
补充2：无法Push时，是远程仓库的版本比本地版本更新，此时建议先Pull再Push，Pull时可能会出现冲突，需要对冲突进行处理。
6.3 从远程仓库拉取数据：Fetch、Pull、Clone
6.3.1 Fetch
git fetch会将远程仓库拉取到本地，若远程仓库中有领先于本底仓库的版本，fetch后当前分支不会只想最新的commit记录，此时可以使用merge命令来讲远程仓库分支合并到当前分支。
6.3.2 Pull
git pull相当于git fetch+git merge，省却了可能的合并操作，但在远程仓库分支和本地分支有冲突时，会拉取失败。
6.3.3 Clone
Clone会将远程仓库中的所有内容拉取到本地，不止是文件，还有项目的历史记录、分支、标签等信息。
Clone适合在第一次从远程仓库拉取到本地仓库时使用，而之后都应该使用Fetch和Pull。
6.4 删除远程分支
使用git push origin :cat可以删除远程仓库，通过推送空内容到origin上的cat分支来变相地将其删除。
七、其他知识
7.1 临时切换手头的工作
当你正在做某项工作，做了一些修改，但还没有完成，但临时需要去处理更紧急的工作。当你切换手头的工作时，需要把当前工作区/暂存区中的修改存储起来，避免影响后续切换的工作，如commit时把前一个工作修改的内容提交到当前工作的分支中去了。
最简单的方法时直接add和commit，然后再切换到需要处理的工作所在的分支。处理完后，再返回继续手头的工作，此时可以拆开重做之前的commit，因为该工作还未完成。当然，也可以不拆开重做，完成工作后再单独使用一个commit即可，一个工作分成了两个commit完成。
还有一种方法，就是Git的Stash功能。你可以把它看成一个临时文件仓库，你先把当前已经完成的工作放入到该临时文件仓库中，然后再切换工作。此时，这些文件不再显示在工作区中，可以使用干净的工作区来完成所切换的工。完成后再切换回原来的分支，从临时文件仓库中将文件取出来即可，然后继续完成未完成的工作。使用方式如下
- 将文件放入Stash：
git stash - 查看Stash：
git stash list - 将文件取出来放回工作区
git stash pop stash@{k}（用stash@{k}指定需要拿回的文件）
7.2 Git Flow
Git Flow是一套开发流程规范，类似的还有GitHub Flow和GitLab Flow等。Git Flow建议将分支分为Master分支、Develop分支、Hotfix分支、Release分支和Feature分支，各分支负责不同的功能：
- Production分支（Master分支）：用于存放稳定、随时可上线的项目版本。这个分支只能从其他分支合并，不能在这个分支直接修改。通常会在该分支上打标签
- Develop分支：开发分支的基础分支，当需要新增功能时，从该分支分离出Feature分支。Feature分支上的功能完成后，又合并到该分支
- Feature分支：用于开发新功能的分支，从Develop分支中分离而来，最后也要合并到Develop分支中去
- Release分支：当Develop分支足够成熟时，将其合并到Release分支进行测试，完成测试后会合并到Master分支和Develop分支。
- Hotfix分支：线上出现Bug时，会从Master分支划分出一个Hotfix来进行修复。修复完成后，合并回Master分支，同时也要合并到Develop分支。
参考文献
菜鸟教程：Git教程
《Git 从入门到精通》（高见龙 著）