Git 原理与使用进阶：远程协作及企业级开发模型

最后记得将 .gitignore 本身也提交到远程。

1.8 给命令配置别名

Git 支持命令别名以简化输入。例如将 git status 简写为 git st：

git config --global alias.st status

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

2. 标签管理

2.1 理解标签

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

2.2 创建标签

打标签非常简单，切换到目标分支后执行：

git tag [name]

默认打在最新提交的 commit 上。也可指定 commit ID 打标签：

git tag [name] [commit_id]

查看标签列表使用 git tag，按字母排序。带说明的标签可使用 -a 和 -m 参数：

git tag -a v1.0 -m "Version 1.0 release"

2.3 操作标签

本地创建的标签不会自动推送到远程。删除本地错误标签可直接移除。推送单个标签：

git push origin <tagname>

批量推送所有标签：

git push origin --tags

若需删除远程标签，先从本地删除，再推送空引用：

git push origin :refs/tags/<tagname>

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

3.1 完成准备工作

模拟多人协作环境，需在另一台机器（或同一台的不同目录）克隆同一项目仓库。

3.2 协助开发

实际开发中，严禁直接在 master 分支修改代码以保证稳定。新功能应在独立分支开发。

1. 开发者 1 在 dev 分支修改文件并提交并推送。
2. 开发者 2 拉取最新代码后，在同一文件进行修改并推送。
3. 若发生冲突（如两人修改了同一行），Git 会提示合并冲突。需手动编辑文件解决冲突，保留所需内容，然后提交。

解决冲突后再次提交，远端仓库即可看到更新。双方通过 pull/add/commit/push 循环协作，遇到冲突及时解决。

3.3 将内容合并进 master

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

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

# 切换至 master，拉取最新
checkout master
git pull
# 合并 dev 分支
merge dev
# 推送到远程
push origin master

合并成功后，可删除不再需要的 dev 分支。

多人协作标准流程总结：

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

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

4.1 协助开发 1

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

开发者 1 创建 feature-1 分支，开发功能 1 并推送。 开发者 2 创建 feature-2 分支，开发功能 2 并推送。 此时双方互不影响，远端仓库可见两个新分支。

若开发者 2 请假，开发者 1 可协助其继续开发。需先在本地拉取 feature-2 分支并与远程关联：

git checkout feature-2
git pull origin feature-2

随后进行代码修改并推送。

4.2 协助开发 2

开发者 2 复工后，需确保本地分支与远程关联，才能正常拉取开发者 1 的代码：

git fetch origin
git merge origin/feature-2

若出现无效拉取提示，需设置本地分支追踪远程分支。

4.3 将内容合并进 master

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

1. 开发者 2 先将 feature-2 合并入 master 并推送。
2. 开发者 1 拉取最新 master，将 feature-1 合并入 master 并推送。
3. 确认无误后，删除 feature-1 和 feature-2 远程分支。

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

远程删除分支后，本地 git branch -a 仍可能显示旧分支。这是因为本地缓存了远程信息。

清理这些过期引用可使用：

git remote prune origin

此命令会删除本地指向已不存在远程分支的引用。本地分支删除则使用常规 git branch -d。

6. 企业级开发模型

6.1 企业级开发流程

软件交付包含规划、编码、构建、测试、发布、部署和维护。随着规模扩大，开发团队（Dev）与运维团队（Ops）常存在诉求冲突：前者追求变化，后者追求稳定。DevOps 文化旨在弥合这一鸿沟，通过自动化流程实现快捷、频繁且可靠的交付。

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

6.2 系统开发环境

常见环境包括：

1. 开发环境：日常调试，开启错误报告。
2. 测试环境：开发到生产的过渡，验证基本功能。
3. 预发布环境：配置与生产一致，作为上线前的最后一道防线。
4. 生产环境：正式对外服务的线上环境。

大型公司可能还包含仿真/灰度环境以满足不同版本测试需求。

6.3 Git 分支设计规范

企业级常用 Git Flow 模型，主要分支定义如下：

• master：主分支，只读，用于部署正式发布。任何情况下不允许直接修改，发布时需打标签记录。
• release：预发布分支，基于 develop 创建，用于提测。命名如 release/version_time。
• develop：开发分支，基于 master 创建，整合所有功能代码，部署到开发环境。
• feature：功能分支，基于 develop 创建，开发新功能。命名如 feature/user_create。完成后合并回 develop。
• hotfix：紧急修复分支，基于 master 创建，修复线上 Bug。完成后合并至 master 和 develop。

选择分支模型应结合团队实际需求，目标是提升协作效率与稳定性。

6.4 企业级项目管理实战—准备工作

使用企业版 Git 平台（如 Gitee 企业版）创建项目，邀请团队成员加入企业及项目，分配相应权限。

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

以订单管理需求为例：

1. 基于 develop 创建 feature/yb_20231010_pay 分支开发。
2. 开发完毕发起代码评审，审查通过后合并入 develop。
3. 自测通过后，基于 develop 创建 release/xxx 分支交由测试。
4. 测试通过（含预发布）后，合并入 master。
5. 线上验证通过后，删除 feature 分支。

Bug 修复策略：

• 测试环境 Bug：直接在 feature 分支修复，重新提测。
• 预发布环境 Bug：回归 develop，若存在则修复，否则排查环境差异。
• 正式环境 Bug：回归 release 和 develop，若存在则修复，否则排查兼容性问题。
• 紧急修复：基于 master 创建 hotfix/xxx 分支，修复后发布验证，再合并回 develop 并删除 hotfix 分支。