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

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。

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