1. 远程操作
1.1 理解分布式版本控制系统
我们之前讨论的工作区、暂存区、版本库等概念，都是在本地计算机上进行的。Git 本质上是分布式版本控制系统。这意味着每个人的电脑上都有一个完整的版本库副本。工作时无需联网，因为数据就在本地。
多人协作时，如果你们都在修改同一个文件，只需将各自的修改推送给对方即可同步。这种架构安全性更高，即使某台电脑损坏，从其他成员处复制一份即可恢复。虽然理论上不需要中央服务器也能工作，但实际场景中通常会有一台充当'中央服务器'的机器，用于方便地交换修改。有了它，即便本地硬盘故障导致数据丢失，也能快速找回。
1.2 远程仓库
同一个 Git 仓库可以分布到不同机器上。最初只有一台机器有原始版本库，其他机器通过'克隆'获取副本。每台机器的版本库地位平等，没有主次之分。
现实中，通常找一台 24 小时开机的电脑充当服务器角色，其他人从中克隆一份到本地，各自提交后推送到服务器，也从服务器拉取他人的提交。搭建 Git 服务器对初学者来说略显复杂，目前业界常用 GitHub 或 Gitee（码云）等托管服务来提供远程仓库支持。
1.3 新建远程仓库
在托管平台上创建新项目仓库，填写基本信息后即可成功。创建后可设置仓库为开源或私有。新仓库默认只有一个 master 分支，本地已有的分支也会随之被管理起来。
1.4 克隆远程仓库—HTTPS/SSH 协议
克隆远端仓库到本地使用 git clone 命令，后跟仓库链接。链接可在托管平台获取。
Git 最常用的两种传输协议是 SSH 和 HTTPS。SSH 基于公钥加密，安全性高，需将公钥上传至服务器；HTTPS 则无需额外配置，直接克隆即可。
使用 SSH 方式克隆时，若未添加公钥，服务器会拒绝连接。此时需要生成 SSH Key：
ssh-keygen -t rsa -C "[email protected]"
生成的私钥 id_rsa 切勿泄露，公钥 id_rsa.pub 可添加到托管平台的 SSH 设置中。认证通过后即可顺利克隆。
克隆完成后，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 文件，列出要忽略的文件名或模式即可。
例如忽略所有 .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，标签更具可读性。
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 在
dev分支修改文件并提交并推送。 - 开发者 2 拉取最新代码后，在同一文件进行修改并推送。
- 若发生冲突（如两人修改了同一行），Git 会提示合并冲突。需手动编辑文件解决冲突，保留所需内容，然后提交。
解决冲突后再次提交，远端仓库即可看到更新。双方通过 pull/add/commit/push 循环协作，遇到冲突及时解决。
3.3 将内容合并进 master
功能开发完毕后，需合并至 master 分支。
方法一：使用 Pull Requests（在线合并）。 方法二：本地合并。
# 切换至 master，拉取最新
checkout master
git pull
# 合并 dev 分支
merge dev
# 推送到远程
push origin master
合并成功后，可删除不再需要的 dev 分支。
多人协作标准流程总结：
- 尝试推送自己的修改。
- 若失败（远程已更新），先
pull合并。 - 若有冲突，解决冲突并提交。
- 无冲突或解决后，再次
push。 - 功能完成后，合并入
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。
- 开发者 2 先将
feature-2合并入master并推送。 - 开发者 1 拉取最新
master，将feature-1合并入master并推送。 - 确认无误后，删除
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 系统开发环境
常见环境包括：
- 开发环境：日常调试，开启错误报告。
- 测试环境：开发到生产的过渡，验证基本功能。
- 预发布环境：配置与生产一致，作为上线前的最后一道防线。
- 生产环境：正式对外服务的线上环境。
大型公司可能还包含仿真/灰度环境以满足不同版本测试需求。
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 模型的实践
以订单管理需求为例：
- 基于
develop创建feature/yb_20231010_pay分支开发。 - 开发完毕发起代码评审，审查通过后合并入
develop。 - 自测通过后，基于
develop创建release/xxx分支交由测试。 - 测试通过（含预发布）后，合并入
master。 - 线上验证通过后，删除
feature分支。
Bug 修复策略：
- 测试环境 Bug：直接在
feature分支修复，重新提测。 - 预发布环境 Bug：回归
develop，若存在则修复，否则排查环境差异。 - 正式环境 Bug：回归
release和develop，若存在则修复，否则排查兼容性问题。 - 紧急修复：基于
master创建hotfix/xxx分支，修复后发布验证，再合并回develop并删除hotfix分支。
