Linux 系统进阶：Git 远程协作与分支管理实战

*.so
*.ini

验证方法：运行 git status，若显示 working tree clean 且未提示新增文件，说明生效。

若需强制添加被忽略的文件，可使用 -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 打上标签。相比难以记忆的 commit id，tag 提供了更易读且有意义的里程碑标识，便于回退到重要版本。

2.2 创建标签

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

git tag [name]

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

git tag [name] [commit-id]

查看所有标签：

git tag

标签按字母排序而非时间顺序。可用 git show [tagname] 查看详细信息。

创建带说明的标签：

git tag -a [tagname] -m "说明文字"

2.3 操作标签

本地创建的标签不会自动推送到远程。若打错，可直接在本地删除。若要推送单个标签：

git push origin <tagname>

一次性推送所有标签：

git push origin --tags

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

git push origin --delete <tagname>

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

3.1 完成准备工作

假设已完成本地基本操作（分支、回退、冲突解决等）。现在模拟多人协作：在另一台电脑（或环境）上克隆同一个项目仓库。

3.2 协助开发

实际项目中，通常不允许直接在 master 分支修改代码以保证稳定。新功能应在独立分支开发。

1. 在远程仓库新建 dev 分支并拉取到本地。
2. 开发者 A 在 dev 分支下修改文件并提交并推送。
3. 开发者 B 拉取最新代码，同样修改同一文件的不同位置。
4. 此时会产生合并冲突。需手动编辑文件解决冲突（保留双方需要的内容），然后提交。
5. 再次推送，冲突解决成功。

协同开发流程：不断 pull/add/commit/push，遇到冲突及时处理。

3.3 将内容合并进 master

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

方法一：Pull Requests 在托管平台发起合并请求，审查通过后合并。

方法二：本地合并

1. 切换至 master 分支，pull 确保本地最新。
2. 切换至 dev 分支，合并 master（若有冲突在此处理）。
3. 切换回 master 分支，合并 dev 分支。
4. 推送 master 至远程。

合并完成后，可删除不再使用的 dev 分支。

协作总结：

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

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

4.1 协助开发 1

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

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

此时各分支互不影响。若开发者 B 生病，开发者 A 可协助继续开发 feature-2。

4.2 协助开发 2

开发者 A 需在自己的机器上切换到 feature-2 分支：

1. 先 pull 远端内容，关联远程分支。
2. 修改文件并提交。
3. 推送内容。

开发者 B 康复后，需设置本地 feature-2 与远程 origin/feature-2 的链接关系，以便正常 pull/push。

4.3 将内容合并进 master

1. 开发者 B 率先完成，merge feature-2 到 master，推送。
2. 开发者 A 完成后，同样 merge feature-1 到 master。
   • 注意：合并前先 pull 确保 master 最新。
   • 若有冲突，建议在 feature 分支处理后再合并。
3. 推送 master 至远程。
4. 删除已合并的 feature 分支。

5. 清理已删除的远程分支

删除远程分支后，本地 git branch -a 仍可能显示旧分支。使用 git remote prune origin 命令可清理本地缓存的远程分支引用。

6. 企业级开发模型

6.1 企业级开发流程

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

Git 作为分布式版本控制系统，是代码管理的核心工具，对 DevOps 至关重要。

6.2 系统开发环境

常见环境包括：

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

6.3 Git 分支设计规范

常用 Git Flow 模型：

• master：主分支，只读，用于部署正式发布环境。不可删除，推送需打标签。
• release：预发布分支，基于 develop 创建，用于提测。命名如 release/version_time。
• develop：开发分支，基于 master 创建，保持最新完成及 bug 修复后的代码。
• feature：功能分支，基于 develop 创建，开发完成后合并回 develop。命名如 feature/user_create。
• hotfix：紧急修复分支，基于 master 创建，修复后合并至 master 和 develop。

不同团队规范会有差异，核心目标是效率与稳定。

6.4 企业级项目管理实战

在企业版托管平台（如 Gitee 企业版）创建项目，邀请团队成员加入企业和项目，分配仓库权限。

6.5 开发场景—基于 Git Flow 模型的实践

1. 需求开发：基于 develop 创建 feature/xxx 分支，开发完毕合并入 develop。
2. 测试准备：develop 自测通过后，创建 release/xxx 分支交由测试。
3. 发布：测试通过后，合并入 master。
4. Bug 修复：
   • 测试环境 Bug：在 feature 分支修复。
   • 预发布环境 Bug：回归 develop，确认问题后修复。
   • 正式环境 Bug：基于 master 创建 hotfix/xxx 分支，修复后合并至 master 和 develop。

Git 分支模型的选择应服务于团队需求，而非盲目照搬。