Git 原理与进阶使用：远程协作、标签管理与企业级模型

Git 原理与进阶使用：远程协作、标签管理与企业级模型

1. 远程操作

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

我们日常接触的工作区、暂存区和版本库通常都在本地，即你的计算机上。Git 是分布式版本控制系统，这意味着每个人的电脑上都有一个完整的版本库。工作时无需联网，因为数据就在本地。

多人协作时，如果各自修改了同一文件，只需将各自的修改推送给对方即可同步。分布式系统安全性更高，即使某台电脑损坏，从他人处复制一份即可恢复。实际使用中，通常会有一台充当'中央服务器'的机器用于方便交换修改，但它并非必需，只是提高了效率。

1.2 远程仓库

同一个 Git 仓库可以分布到不同机器上。早期只有一台机器有原始版本库，其他机器通过'克隆'获取副本。每台机器的版本库地位平等，没有主次之分。

虽然一台电脑可以克隆多个仓库，但现实中通常找一台电脑充当服务器角色，24 小时开机。大家从服务器克隆一份到本地，提交后推送到服务器，也从服务器拉取他人的提交。搭建 Git 服务器较为繁琐，目前常用托管服务如 GitHub 或 Gitee（码云）。

1.3 新建远程仓库

在托管平台上创建项目仓库，填写基本信息并设置开源或私有属性。创建成功后，默认只有一个 master 分支，本地的分支也会随之被管理起来。

1.4 克隆远程仓库—HTTPS/SSH 协议

使用 git clone 命令下载远端仓库到本地，链接可从仓库页面获取。

• SSH 协议：使用公钥加密和登录机制，安全性高。需将公钥上传至服务器。
• HTTPS 协议：直接克隆，无需配置密钥，但每次推送可能需要输入密码。

若使用 SSH 克隆失败，需检查 SSH Key。在用户主目录下查看 .ssh 目录，若无 id_rsa 和 id_rsa.pub，需生成新的密钥对。私钥不可泄露，公钥可上传至远程仓库设置中。添加公钥后，再次执行 clone 即可成功。

克隆后，Git 会自动将本地 master 分支与远程 master 分支对应，远程仓库默认名称为 origin。使用 git remote 或 git remote -v 可查看远程库信息。

1.5 向远程仓库推送

本地修改完成后，需先提交至本地仓库。确保全局配置的 name 和 email 与远程仓库账号一致，否则可能报错。使用 git push 命令将本地分支版本上传到远程。

git push origin master

这将把本地 master 分支推送到远程主机 origin 的 master 分支。使用 SSH 协议通常无需每次输入密码，而 HTTPS 则可能需要。

1.6 拉取远程仓库

当远程仓库领先于本地时，需使用 git pull 命令获取代码并合并到本地。

git pull origin master

这能确保本地仓库保持最新版本。

1.7 忽略特殊文件

某些文件不应提交到远程，如包含数据库密码的配置。在工作区根目录创建 .gitignore 文件，填入要忽略的文件名或模式，Git 会自动忽略这些文件。

例如，忽略所有 .so 和 .ini 结尾的文件：

*.so
*.ini

验证可使用 git status，显示 working tree clean 即生效。若需强制添加被忽略的文件，可使用 git add -f。若规则有误，可用 git check-ignore 检查具体哪行规则匹配了该文件。对于 .gitignore 自身，可通过添加例外规则 !.gitignore 来保留。

1.8 给命令配置别名

Git 支持命令简化，例如将 git status 简化为 git st。

git config --global alias.st status

--global 参数使配置对所有仓库生效。不过建议初学者先熟悉完整命令，再根据习惯配置别名。

2. 标签管理

2.1 理解标签

标签（tag）是对某次 commit 的标识，相当于一个易记的别名。例如发布 v1.0 版本时打上一个标签，便于后续回退或定位里程碑。相比难以记忆的 commit id，tag 更具可读性。

2.2 创建标签

切换到目标分支，使用 git tag [name] 创建标签，默认打在最新提交上。也可指定 commit id 打标：

git tag v1.0 abc1234

查看所有标签：

git tag

标签按字母排序。使用 git show [tagname] 可查看标签详情。带说明的标签可使用 -a 和 -m 参数：

git tag -a v1.0 -m "Release version 1.0"

2.3 操作标签

本地标签不会自动推送到远程。删除本地标签：

git tag -d <tagname>

推送单个标签：

git push origin <tagname>

推送所有标签：

git push origin --tags

删除远程标签需先从本地删除，再从远程删除：

git push origin --delete <tagname>

3. Git 实战场景—多人协作一

3.1 完成准备工作

模拟多人协作环境，在同一项目中 clone 两份仓库到不同机器或目录，分别代表开发者 A 和 B。

3.2 协助开发

实际开发中，不建议直接在 master 分支修改。新功能应在独立分支开发。

1. 在远程创建 dev 分支并拉取到本地。
2. 开发者 A 在 dev 分支修改文件并提交并推送。
3. 开发者 B 拉取最新代码，同样修改文件并推送。
4. 若发生冲突（如两人修改同一行），Git 会提示合并冲突。需手动编辑文件解决冲突，标记后重新提交。

3.3 将内容合并进 master

功能开发完毕后，需合并回 master 分支。

方法一：使用 Pull Requests 在线合并。 方法二：本地合并。

# 切换至 master，拉取最新
checkout master
git pull

# 合并 dev 分支
merge dev

# 推送至远程
push origin master

合并后，确认无误可删除临时分支：

git branch -d dev
git push origin --delete dev

多人协作流程总结：

1. 尝试推送自己的修改。
2. 若失败，因远程更新，先拉取合并。
3. 若有冲突，解决冲突并提交。
4. 无冲突后再次推送。
5. 功能完成，合并入 master，删除分支。

4. Git 实战场景—多人协作二

4.1 协助开发 1

多需求并行时，每个需求创建独立的 feature 分支。

• 开发者 1 创建 feature-1 分支，开发功能 1，推送至远程。
• 开发者 2 创建 feature-2 分支，开发功能 2，推送至远程。

此时双方互不影响。若开发者 2 请假，开发者 1 可切换至 feature-2 分支继续开发。

4.2 协助开发 2

开发者 1 需先拉取远程 feature-2 分支，建立本地关联，避免推送失败。

git fetch origin
checkout -b feature-2 origin/feature-2

修改完成后推送。开发者 2 复工后，也需拉取最新代码，确保本地与远程一致。

4.3 将内容合并进 master

各功能开发完毕，依次合并至 master。

1. 开发者 2 先将 feature-2 合并入 master 并推送。
2. 开发者 1 拉取最新 master，将 feature-1 合并入 master 并推送。
3. 清理已完成的 feature 分支。

注意：合并前务必保证本地 master 是最新的，避免引入旧代码导致冲突。

5. 解决 branch -a 打印已被删除的远程分支的办法

删除远程分支后，本地 git branch -a 仍可能显示已删除的远程分支。使用以下命令清理：

git remote prune origin

这将移除本地指向不存在远程分支的记录。

6. 企业级开发模型

6.1 企业级开发流程

软件交付包括规划、编码、构建、测试、发布、部署和维护。随着规模扩大，DevOps 文化应运而生，弥合开发与运维之间的鸿沟，实现自动化交付。

Git 作为代码管理的核心工具，在 DevOps 流程中至关重要。

6.2 系统开发环境

常见环境包括：

• 开发环境：日常调试，开启错误报告。
• 测试环境：开发到生产的过渡，进行功能测试。
• 预发布环境：配置与生产环境一致，作为上线前的最后一道防线。
• 生产环境：正式对外服务的线上环境。

6.3 Git 分支设计规范

推荐采用 Git Flow 模型，规范如下：

• master 分支：只读，用于部署正式发布环境，禁止直接修改，发布时打标签。
• release 分支：基于 develop 创建，用于提测，命名如 release/v1.0_20231010。
• develop 分支：开发分支，包含最新完成及 bug 修复的代码。
• feature 分支：新功能开发，基于 develop 创建，命名如 feature/user_create，完成后合并回 develop。
• hotfix 分支：紧急修复线上 Bug，基于 master 创建，修复后合并至 master 和 develop。

6.4 企业级项目管理实战

使用 Gitee 企业版等平台管理项目。创建项目后，邀请团队成员加入企业和项目，分配仓库权限。

6.5 开发场景—基于 git flow 模型的实践

以订单管理新需求为例：

1. 基于 develop 创建 feature/yb_20231010_pay 分支开发。
2. 开发完毕发起 Merge Request，审查通过后合并至 develop。
3. 自测通过后，基于 develop 创建 release 分支交由测试。
4. 测试通过，合并入 master。
5. 线上验证通过后，删除 feature 分支。

Bug 修复策略：

• 测试环境 Bug：在 feature 分支修复，重新提测。
• 预发布环境 Bug：回归 develop，若存在则修复，否则排查环境差异。
• 正式环境 Bug：基于 master 创建 hotfix 分支，修复后合并至 master 和 develop。

掌握这些规范与流程，能帮助团队在复杂的项目中保持高效与稳定。