当前位置：首页 > news >正文

Git - 2（ 12000 字详解）

news 来源：原创 2025/5/17 10:54:39

一：远程调用

1.1 理解分布式版本控制系统

当前我们讨论的工作区、暂存区、版本库等等都是在本地进行的，也就是在你的笔记本电脑或计算机上。但是 Git 实际上是一个分布式版本控制系统。每个人的电脑上都有一个完整的版本库，因此在工作时不需要连接互联网，因为所有的版本信息都保存在自己的电脑上。

由于每个人的电脑上都拥有完整的版本库，团队成员可以轻松协作。例如，如果你在自己的电脑上修改了文件 A，而你的同事也在他的电脑上对同一个文件进行了修改，那么你们只需相互推送各自的修改，便能够看到对方的更改。这种分布式的特性使得团队协作变得更加灵活和高效。

在这里插入图片描述

分布式版本控制系统的安全性非常高，因为每个人的电脑上都有完整的版本库。如果某个人的电脑损坏了，只需从其他人那里复制一个即可继续工作。这种设计增加了数据的冗余性，使得项目的安全性大大提升。

在实际使用分布式版本控制系统时，通常不在两个人的电脑之间直接推送版本库的修改，因为他们可能不在同一个局域网络中，或者一台电脑可能没有开机。此外，分布式系统通常还会有一台充当“中央服务器”的电脑，用于方便地交换大家的修改。尽管没有这台中央服务器，团队成员仍然可以本地工作，只是交换修改会变得不便。通过设置这个中央服务器，可以有效避免因本地故障而导致的数据丢失问题。

1.2 远程仓库

Git 是一个分布式版本控制系统，同一个 Git 仓库可以分布在不同的机器上。最初肯定只有一台机器拥有一个原始版本库，其他机器可以通过“克隆”原始版本库来获取副本，注意每台机器的版本库都是相同的，并没有主次之分。

其实一台电脑上也是可以克隆多个版本库，只要这些版本库不位于同一个目录下。但是现实中很少有人在一台电脑上创建多个远程库，因为这样做没有实际意义，并且如果硬盘损坏，将会导致所有库都丢失。因此不建议在一台电脑上克隆多个仓库。

通常的做法是找一台电脑充当服务器的角色，这台服务器能够全天候开机。其他团队成员从这个“服务器”仓库克隆一份到各自的电脑上，并将自己的提交推送到服务器仓库，同时也能从服务器仓库拉取其他人的提交。

GitHub 提供了一个便捷的平台，专门用于托管 Git 仓库。只需注册一个 GitHub 账号，就可以免费获取远程仓库。由于 GitHub 是海外网站，速度可能较慢，因此在此我们统一使用码云来托管代码。接下来，我们从零开始使用码云远程仓库。

1.3 新建远程仓库

新建远程项目仓库：

在这里插入图片描述

接着填写基本信息：

在这里插入图片描述

创建成功后我们对仓库进行一个基本的设置，把仓库进行开源

在这里插入图片描述

在创建好的远程仓库中，我们可以看到之前在本地学习过的分支也存在于远程仓库中，并且都得到了相应的管理。新建的仓库初始时只有一个默认的 master 分支。

在这里插入图片描述

1.4 克隆远程仓库

要将远程仓库克隆或下载到本地，可以使用 git clone 命令，后面接上远程仓库的链接。这个链接可以在仓库页面找到，点击“克隆/下载”即可获取远程仓库的链接。

在这里插入图片描述

SSH 协议和 HTTPS 协议是 Git 最常用的两种数据传输协议。SSH 协议采用公钥加密和公钥登录机制，确保了安全性和实用性。在使用 SSH 协议时，需要将我们的公钥上传到服务器，由 Git 服务器进行管理。而使用 HTTPS 协议时则没有额外要求，可以直接克隆仓库。

git clone https://gitee.com/hyb91/git_teaching.git # HTTP 方式
git clone git@gitee.com:hyb91/git_teaching.git # SSH 方式

注意：如果采用 SSH 的方式需要把公钥添加到远端库中，不然会被服务器拒绝 clone 请求，如果没有公钥私钥的话就按照下面的步骤进行创建：

首先在用户主目录下检查是否存在 .ssh 目录。如果该目录存在，进一步查看其中是否包含 id_rsa 和 id_rsa.pub 这两个文件。如果这两个文件已经存在，可以直接跳到下一步；如果没有，则需要新建 SSH Key。

# 注意要输⼊⾃⼰的邮箱，然后⼀路回⻋，使⽤默认值即可
hyb@139-159-150-152:~$ ssh-keygen -t rsa -C "2689241679@qq.com"

如果一切顺利，你可以在用户主目录下找到 .ssh 目录，内部会有 id_rsa 和 id_rsa.pub 这两个文件。它们构成了 SSH Key 的秘钥对，其中 id_rsa 是私钥，必须保持机密，不得泄露；而 id_rsa.pub 是公钥，可以放心地分享给任何人，接着就可以把公钥填写到远程仓库里了：

在这里插入图片描述

点击确认后，系统会要求进行身份认证，你只需输入你的账号密码即可。如果有多人协作开发，GitHub 或 Gitee 允许添加多个公钥，只需将每个人电脑上的 Key 添加到 GitHub 或 Gitee，即可在每台电脑上进行提交和推送。克隆远程仓库后，Git 会自动将本地的 master 分支与远程的 master 分支关联起来，远程仓库的默认名称为 origin。在本地，可以使用 git remote 命令查看远程库的信息。

hyb@139-159-150-152:~/git_teaching$ git remote
originhyb@139-159-150-152:~/git_teaching$ git remote -v  # 能看到更多信息
origin        git@gitee.com:hyb91/git_teaching.git (fetch)
origin        git@gitee.com:hyb91/git_teaching.git (push) # 如果没有推送权限就看不到 push 地址

1.5 向远程仓库推送

成功克隆远程仓库后，我们可以向仓库提交内容，例如新增一个 file.txt 文件。

# 新建⽂件
hyb@139-159-150-152:~/git_teaching$ ls
README.en.md  README.md
hyb@139-159-150-152:~/git_teaching$ vim file.txt
hyb@139-159-150-152:~/git_teaching$ cat file.txt
hello git# 提交⽂件
hyb@139-159-150-152:~/git_teaching$ git add .
hyb@139-159-150-152:~/git_teaching$ git commit -m"create file.txt"
[master 7ce3183] create file.txt1 file changed, 1 insertion(+)create mode 100644 file.txt

在提交内容时要注意，如果之前设置过全局的 name 和 email，这两个配置需要与 Gitee 上配置的用户名和邮箱一致，否则提交时可能会出错。如果从未设置过全局的 name 和 email，第一次提交时也会报错，这时需要重新进行配置，同样要确保与 Gitee 上的用户名和邮箱一致。

完成本地提交后，要将内容推送至远程仓库，需要使用 git push 命令。该命令用于将本地分支版本上传到远程并进行合并，命令格式如下：

git push <远程主机名> <本地分⽀名>:<远程分⽀名># 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>

此时我们要将本地的 master 分支推送到 origin 主机的 master 分支就可以：

hyb@139-159-150-152:~/git_teaching$ git push origin master

由于我们使用的是 SSH 协议，因此在推送时无需每次都输入密码，这样方便了我们的操作。如果你使用的是 HTTPS 协议，那么每次推送时都必须输入口令，这会比较麻烦。接下来，让我们来看一下码云远端。

在这里插入图片描述

此时代码已经被推送至远端了：

在这里插入图片描述

1.6 拉取远程仓库

首先在 gitee 上点击 README.md 文件并在线修改它:

在这里插入图片描述

此时，远程仓库的版本领先于本地仓库一个版本。为了使本地仓库保持最新状态，我们需要从远程拉取代码并将其合并到本地。Git 提供了 git pull 命令，用于从远程获取代码并合并到本地版本。命令格式如下

git pull <远程主机名> <远程分⽀名>:<本地分⽀名># 如果远程分⽀是与当前分⽀合并，则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>

hyb@139-159-150-152:~/git_teaching$ git pull origin master

此时就拉取成功了。

二：配置 Git

2.1 忽略特殊文件

在日常开发中，有些文件不应该提交到远程仓库，例如保存数据库密码的配置文件。为了让 Git 忽略这些文件，我们可以在 Git 工作区的根目录下创建一个特殊的 .gitignore 文件，将需要忽略的文件名添加进去，Git 就会自动忽略这些文件。Gitee 在创建仓库时也可以为我们生成 .gitignore 文件，我们只需要主动勾选该选项。

在这里插入图片描述

如果当时没有选择该选项，也可以在工作区手动创建一个 .gitignore 文件。无论采用哪种方式，最终都能得到一个完整的 .gitignore 文件。例如，如果我们想忽略所有以 .so 和 .ini 结尾的文件，可以将以下内容添加到 .gitignore 文件中：

# 省略选择模本的内容
...# My configurations:
*.ini
*.so

但是有时候我们就是想要将一个被 .gitignore 忽略的文件添加到 Git 中。在这种情况下，可以使用 -f 选项强制添加该文件。

git add -f [filename]

如果你发现 .gitignore 文件可能存在问题，需要查找哪个规则写错了，比如希望添加 a.so 文件但是无法添加，此时可以使用 git check-ignore 命令来检查：

hyb@139-159-150-152:~/git_teaching$ git check-ignore -v a.so
.gitignore:3:*.so        a.so

Git 会告诉我们是 .gitignore 的第 3 行规则忽略了该文件，这样我们就可以修订相应的规则。还有一些时候，当我们编写规则排除了一些文件时，比如使用 .* 规则排除了 .gitignore 文件。虽然可以通过 git add -f 强制添加该文件，但对于有强迫症的同学来说，他们希望不破坏 .gitignore 的规则。在这种情况下，可以添加一条例外规则来解决这个问题。

# 排除所有.开头的隐藏⽂件:
.*# 不排除.gitignore
!.gitignore

2.2 给命令配置别名

在使用 Git 的过程中，有些命令确实显得冗长，让人头疼。不过幸运的是，Git 支持对命令进行简化！比如我们可以将 git status 简化为 git st，对应的命令为：

$ git config --global alias.st status

–global 参数是全局参数，意味着该命令在这台电脑的所有 Git 仓库中都有效。如果不加，该命令只对当前仓库生效。不过，我个人不建议大家现在就使用别名配置，建议等到工作后再进行简化。此时尽量手动完成所有命令，尽快适应 Git 的使用。

三：标签管理

3.1 创建标签

在 Git 中打标签非常简单。首先，切换到需要打标签的分支上，然后使用命令 git tag [name] 就可以创建一个新标签。此外，你还可以通过命令 git tag 查看所有已创建的标签。

hyb@139-159-150-152:~/git_teaching$ git tag v1.0hyb@139-159-150-152:~/git_teaching$ git tag # 查看所有已创建的标签
v1.0

默认情况下，标签会打在最新提交的 commit 上。如果想要在指定的 commit 上打标签，可以找到该历史提交的 commit ID，然后使用标签命令进行标记。但是要注意，标签不是按时间顺序列出，而是按字母顺序排列。

# 历史记录
hyb@139-159-150-152:~/git_teaching$ git log --pretty=oneline --abbrev-commit
97811ab (HEAD -> master, tag: v1.0, origin/master, origin/HEAD) add .gitignore
60e6b0a update README.md.
7ce3183 create file.txt
c6ce3f0 Initial commit# 对 Initial commit 这次提交打标签
hyb@139-159-150-152:~/git_teaching$ git tag v0.9 c6ce3f0
hyb@139-159-150-152:~/git_teaching$ git tag
v0.9
v1.0

我们可以通过命令 git show [tagname] 来查看标签的详细信息。

hyb@139-159-150-152:~/git_teaching$ git show v1.0
commit 97811abd1d43774aeb54fee32bf4fc76b2b08170 (HEAD -> master, tag: v1.0,
origin/master, origin/HEAD)
Author: hyb91 <2689241679@qq.com>
Date:   Fri May 12 17:27:06 2023 +0800add .gitignorediff --git a/.gitignore b/.gitignore

Git 还支持创建带有说明的标签。可以使用 -a 选项指定标签名，-m 选项添加说明文字，命令的格式为：

git tag -a [name] -m "XXX" [commit_id]

3.2 操作标签

如果标签打错了，可以安全地在本地删除它，因为创建的标签只存储在本地，并不会自动推送到远程。因此，可以放心地删除错误的标签。

hyb@139-159-150-152:~/git_teaching$ git tag
v0.9
v1.0hyb@139-159-150-152:~/git_teaching$ git tag -d v0.9

如果要推送某个标签到远程，使用命令 git push origin <tagname>

hyb@139-159-150-152:~/git_teaching$ git tag
v1.0
hyb@139-159-150-152:~/git_teaching$ git push origin v1.0hyb@139-159-150-152:~/git_teaching$ git push origin --tags # 这是一次性把所有标签推送过去

此时查看远端码云就可以看到标签已经被更新：

在这里插入图片描述

如果标签已经推送到远程，要删除远程标签就麻烦⼀点，需要先从本地删除，然后再从远程删除

hyb@139-159-150-152:~/git_teaching$ git tag
v1.0hyb@139-159-150-152:~/git_teaching$ git tag -d v1.0 # 本地删除hyb@139-159-150-152:~/git_teaching$ git push origin :refs/tags/v1.0 # 远程删除

在这里插入图片描述

四：多人协作

4.1 多人协作案例一

目前我们已经学习了 Git 的一些大概的知识，但是 Git 真正的作用其实是进行多人协作，为了做这个事情，首先我们进行一些准备工作，在 windows 下再 clone 一个项目仓库，模拟多人协作：

在这里插入图片描述

在这里我们就模拟两个人进行任务协作，在实际开发中每个人都会有自己的 gitee 或者 github 账号，如果要多个人进行同一个仓库的协同开发，那么必须将用户添加进开发者，这样用户才有权限进行代码提交：

在这里插入图片描述

到这里我们已经相当于拥有了两个用户，分别在 Linux 和 Windows 上进行同一个项目的协作开发，准备工作也到此结束。目前，我们的仓库中只有一个 master 主分支，但在实际的项目开发中，直接在 master 分支上修改代码是不可接受的，为了确保主分支的稳定性，在开发新功能时，通常会新建其他分支，接下来，我们将在 Gitee 上新建一个 dev 远程分支供我们使用。

在这里插入图片描述

成功创建的远程分支可以通过 Git 拉取到本地，接着进行本地开发工作。接下来我们让两个用户都从远程仓库拉取代码，拉取后将能够看到远程的 dev 分支。然后切换到 dev 分支以便进行本地开发。

hyb@139-159-150-152:~/git_teaching$ vim file.txt
hyb@139-159-150-152:~/git_teaching$ cat file.txt
hello git
complete the first function!hyb@139-159-150-152:~/git_teaching$ git add file.txt
hyb@139-159-150-152:~/git_teaching$ git commit -m "first function"

模拟开发完成后看看码云的状态，可以发现我们已经把代码成功推送到码云，接下来就是进行一些协同开发了。
在这里插入图片描述

如果另一个人也正好要修改 file.txt，他在尝试推送时可能会失败，因为他的最新提交与您的提交存在冲突。解决这个问题的方法很简单：首先使用 git pull 从 origin/dev 获取最新的提交，然后在本地进行合并并解决冲突，最后再进行推送。

在这里插入图片描述

解决冲突后重新推送就可以看见远端的码云能看到我们的提交了：

在这里插入图片描述

通过不断地执行 git pull、git add、git commit 和 git push，两名开发者已经能够开展协同开发了。如果想查看小伙伴的代码，只需执行一次 git pull 即可。需要注意的是，尽管我们在分支上进行多人协作开发，但最终目标是将开发后的代码合并到 master 分支，以确保项目运行的是最新的代码，在把分支合并在 master 后查看码云：

在这里插入图片描述

此时，dev 分支对于我们来说就没用了，那么 dev 分支就可以被删除掉。我们可以直接在远程仓库中将 dev 分支删除掉：

在这里插入图片描述

4.2 多人协作案例二

通常情况下，当有多个需求需要多人同时进行开发时，不会在同一个分支上協作，而是针对每个需求或功能点创建一个独立的 feature 分支。如果现在你和你的伙伴同时有两个需求需要开发，你们可以各自创建一个分支来完成自己的工作。

在上一个部分，我们已经了解了如何在码云上直接创建远程分支。其实，本地创建的分支也可以通过推送的方式发送到远程。在这一部分，我们将探讨使用这种方法进行协作。

# 新增本地分⽀ feature-1 并切换
hyb@139-159-150-152:~/git_teaching$ git branch
dev
* master
* 
hyb@139-159-150-152:~/git_teaching$ git checkout -b feature-1
Switched to a new branch 'feature-1'# 新增需求内容-创建function1⽂件
hyb@139-159-150-152:~/git_teaching$ vim function1
hyb@139-159-150-152:~/git_teaching$ cat function1
Done!# 将 feature-1 分⽀推送到远端
hyb@139-159-150-152:~/git_teaching$ git add function1
hyb@139-159-150-152:~/git_teaching$ git commit -m"add function1"

在这里插入图片描述
此时在本地，你看不到他新建的文档，他也无法看到你新建的文档。推送各自的分支时没有产生任何冲突，彼此互不影响，使用起来非常顺畅！现在，让我们来看一下在远端码云上的状态。

在这里插入图片描述

正常情况下，你和你的伙伴可以在各自的分支上进行专业的开发。不过突发情况总是不可避免，你的伙伴突然生病了，导致需求未能完成，因此需要你来协助开发。他将 feature-2 分支的名称告诉了你。这时，你就需要在自己的机器上切换到 feature-2 分支，以帮助继续完成开发工作。

# 必须先拉取远端仓库内容
hyb@139-159-150-152:~/git_teaching$ git pull# 可以看到远程已经有了 feature-2
hyb@139-159-150-152:~/git_teaching$ git branch -adev
* feature-1masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master# 切换到 feature-2 分支上，可以与远程的 feature-2 分支关联起来，
# 否则将来只使用 git push 推送内容将会失败
hyb@139-159-150-152:~/git_teaching$ git checkout -b feature-2 origin/feature-2
Branch 'feature-2' set up to track remote branch 'feature-2' from 'origin'.
Switched to a new branch 'feature-2'# 查看当前目录下的文件
hyb@139-159-150-152:~/git_teaching$ ls
a.so  b.ini  file.txt  function2  README.en.md  README.md

切换到 feature-2 分支后，你可以看到该分支中的 function2 文件。接下来，你就可以开始帮助小伙伴进行开发工作了。开发完成后，进行推送，然后查看远程状态：

在这里插入图片描述

此时如果你的小伙伴已经基本恢复，可以继续进行自己的开发工作。首先他需要获取你为他开发的内容，在此基础上继续工作。或者如果你已帮助他完成了开发，他也需要在自己的电脑上查看你所编写的代码。

在这里插入图片描述

Pull 无效的原因是因为小伙伴没有将本地 feature-2 分支与远程 origin/feature-2 分支关联起来。按照提示设置本地 feature-2 分支与远程 origin/feature-2 分支之间的链接即可。

在这里插入图片描述

此时，小伙伴的本地代码与远程代码保持严格一致。你和你的小伙伴可以在各自的分支上继续进行协同开发。各自的功能开发完成后，别忘了将代码合并到 master 分支中，这样才能算真正意义上的开发完成。

在这里插入图片描述

此时， feature-1 和 feature-2 分支对于我们来说就没用了，我们可以直接在远程仓库中将 dev 分支删除掉：

在这里插入图片描述

五：企业级开发模型

一个软件从零开始到最终交付，大致经历几个阶段：规划、编码、构建、测试、发布、部署和维护。最初程序相对简单，工作量不大，一个程序员就可以完成所有阶段的任务。但是随着软件产业的快速发展和软件规模的不断扩大，软件的复杂度也逐渐增加，单个程序员已经无法应对。因此，精细化分工开始出现，以应对日益复杂的开发需求。

在这里插入图片描述

在传统的 IT 组织中，开发团队（Dev）和运维团队（Ops）常常面临不同的诉求。开发团队追求变化和创新，而运维团队则更注重系统的稳定性。这种差异导致了双方之间的利益冲突，从而产生了部门间的壁垒，这不利于最大化 IT 价值。

为了弥合开发与运维之间的鸿沟，需要在文化、工具和实践等方面进行一系列变革，这就是 DevOps 所应运而生的目标。DevOps 通过促进跨团队的协作与沟通，力求实现开发与运维之间的无缝连接。

DevOps 是一种强调软件开发人员与 IT 运维技术人员之间沟通与合作的文化、运动或惯例。通过自动化软件交付和架构变更的流程，DevOps 使得软件的构建、测试和发布变得更加快捷、频繁和可靠。DevOps 的软件开发过程包括规划、编码、构建、测试、预发布、发布、运维和监控，显示了其强大的协同能力。

那么，这个故事与我们课程的主题 Git 有何关联呢？软件的迭代在开发人员看来就是对代码进行不断更新与管理。而管理代码的核心工具就是 Git（分布式版本控制系统）。因此，Git 对于开发人员的重要性不言而喻。

5.1 系统开发环境

言归正传，对于开发人员来说，了解系统开发过程中常用的几个环境是非常重要的：

环境	描述
开发环境	开发环境是程序员用于日常开发的服务器。为了方便开发调试，一般会开启全部错误报告和测试工具，这也是最基础的环境。
测试环境	测试环境用于确保程序在正式发布之前能够正常运行。如果一个程序在测试环境中工作不正常，那么就不能将其发布到生产环境。
预发布环境	预发布环境旨在避免因测试环境与线上环境之间的差异而导致的缺陷漏测。该环境的配置基本与生产环境一致，以便在正式发布时更有把握。预发布环境是产品质量的最后一道防线，因为此后项目即将上线。需要注意的是，预发布环境的服务器不在线上集成服务器的范围内，而是独立的一些机器。
生产环境	生产环境指正式提供对外服务的线上环境，例如用户在移动端或 PC 端访问的应用程序都是在生产环境中运行的。

在这里插入图片描述

5.2 Git 分支设计规范

了解了环境的概念后，开发人员通常会根据不同的环境设计相应的分支。

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

5.2.1 master 分支

master 是主分支，唯一且只读，专用于部署到正式发布环境，通常通过合并 release 分支来更新。作为稳定的代码库，master 分支在任何情况下都不允许直接修改代码。产品功能全部实现后，最终会在 master 分支上对外发布，同时所有推送到 master 的代码应打标签（tag）以便追溯。此外，master 分支不得删除。

5.2.2 release 分支

release 是预发布分支，其命名以 release/ 开头，建议的规则为 release/version_publishtime。release 分支主要用于提交给测试人员进行功能测试，发布提测阶段将以 release 分支中的代码为基准。如果在 release 分支中发现问题，需要回归验证 develop 分支以确认问题是否存在。release 分支属于临时分支，产品上线后可以选择删除。

5.2.3 develop 分支

develop 是开发分支，基于 master 分支创建，是唯一的只读分支，始终保持最新的功能完成版本和 bug 修复代码。该分支可部署到开发环境对应的集群。根据需求的规模，可以选择将 feature 分支合并到 develop，或直接在 develop 分支上进行开发，但后者是不太建议的做法。

5.2.4 feature 分支

feature 分支通常用于开发新功能或新特性，基于 develop 分支创建。命名以 feature/ 开头，建议使用的规则为 feature/user_createtime_feature。新特性或功能开发完成后，开发人员需将其合并到 develop 分支。一旦该需求发布上线，相关的 feature 分支应被删除。

5.2.5 hotfix 分支

hotfix 分支用于修复线上 bug，主要针对紧急问题进行补丁处理。当线上出现需要立即修复的问题时，应基于 master 分支创建 hotfix 分支。命名以 hotfix/ 开头，建议的规则为 hotfix/user_createtime_hotfix。问题修复完成后，需要将其合并到 master 和 develop 分支，并推送远程。一旦修复上线，相关的 hotfix 分支应被删除。

5.2.6 总结

这种分支模型实际上是企业常用的 Git 分支设计规范之一，即 Git Flow 模型。但是需要注意，该模型并不适用于所有团队、环境和文化。需要从团队或项目的角度思考：这种分支模型能帮助你们解决哪些问题？它可能带来哪些挑战？这种模式更支持哪种类型的开发？你们是否希望鼓励这种行为？选择分支模型的最终目标是促进软件协作开发的便利。因此，分支模型需要考虑用户的需求，而不是盲目遵循某些所谓的“成功分支模型”。因此，不同公司之间的规范可能会有所不同，但其核心目标始终是提高效率和稳定性。

在这里插入图片描述