Git 主流分支策略有四种，适配不同开发规模。GitFlow 最经典，分主分支 master、开发分支 develop、功能分支 feature、发布分支 release、修复分支 hotfix，适合大型团队、迭代规范的项目。GitHubFlow 极简，仅主分支 + 功能分支，合并后直接部署，适合中小型团队、快速迭代的 Web 项目。GitLabFlow 兼容多环境，主分支 + 环境分支 + 功能分支，支持多环境发布，适合云原生、多环境部署项目。单分支策略 仅主分支，适合小型工具、个人项目，简单轻量。
最佳实践是轻量化 + 规范化，优先选用 GitHubFlow/GitLabFlow，避免 GitFlow 过于复杂。核心规则：主分支（main/master）保持稳定，仅存放可部署代码；所有新功能、bug 修复都从主分支创建独立功能分支，开发完成后提交 PR/MR；代码审查通过后合并，合并后自动部署 / 测试；紧急 bug 用热修复分支，快速合并回主分支。禁止直接提交主分支，定期清理废弃分支，统一分支命名规范（feature/xxx、hotfix/xxx），保证分支整洁、协作高效。
merge 是合并分支，将目标分支的提交合并到当前分支，生成一个新的合并提交，保留完整的分支历史，历史清晰但提交线杂乱。优点：安全、不修改原有提交，适合团队协作；缺点：提交历史臃肿。rebase 是变基，将当前分支的提交“嫁接”到目标分支顶端，重写提交历史，提交线线性整洁。优点：历史干净、无冗余提交；缺点：修改提交哈希，禁止在公共分支使用，易导致团队代码冲突。公共分支用 merge，个人功能分支用 rebase。
快进合并（Fast-forward）：当目标分支是当前分支的直接上游，无分叉时，Git 直接移动指针，不生成新提交，速度快、历史简洁，但无合并记录。非快进合并（Non-fast-forward）：分支存在分叉，必须创建新的合并提交，保留所有分支的合并轨迹，历史可追溯，便于回滚。日常开发建议强制非快进合并（--no-ff），保留合并记录，方便排查问题；个人功能分支可使用快进合并，简化历史。
Git 三种核心合并策略：recursive（默认），处理分支分叉、重命名、文件冲突，适合绝大多数常规合并场景。resolve，仅处理简单的两路合并，不支持复杂分叉，稳定性高，适合简单分支。octopus，支持同时合并多个分支，无需逐个合并，适合批量合并功能分支，但无法处理冲突，仅用于无冲突的批量合并。日常开发默认用 recursive，多分支无冲突合并用 octopus，简单场景用 resolve。
冲突产生于两个分支修改了同一文件的同一行，Git 无法自动合并，需手动解决。步骤：1. 执行合并 / 变基后，Git 提示冲突文件；2. 打开冲突文件，文件中会标记 <<<<<<< HEAD（当前分支）、=======（目标分支）、>>>>>>> 分隔的冲突代码；3. 手动编辑，保留需要的代码，删除冲突标记；4. 执行 git add 冲突文件 标记冲突已解决；5. merge 执行 git commit，rebase 执行 git rebase --continue。示例：修改 User.java 的冲突代码，保留正确逻辑，完成合并。
rebase 冲突是变基过程中，提交与目标分支代码不一致导致的。解决步骤：1. 执行 git rebase 目标分支 出现冲突后，Git 暂停变基；2. 打开冲突文件，删除 Git 标记，编辑保留正确代码；3. 执行 git add 冲突文件 暂存解决后的文件；4. 执行 git rebase --continue 继续变基；5. 重复操作直至所有冲突解决；若放弃变基，执行 git rebase --abort 恢复原状。rebase 冲突需逐次解决每个提交的冲突，比 merge 更精细，仅用于个人分支。
cherry-pick 是拣选提交，将指定的单个 / 多个提交，从一个分支复制到当前分支，不会合并整个分支。用法：git cherry-pick 提交哈希值，支持批量拣选。适用场景：1. 仅需要 A 分支的某个 bug 修复提交，无需合并整个分支；2. 热修复提交同步到开发分支；3. 跨分支复用单个功能提交。优点：精准复用提交，不污染分支；缺点：会生成新的提交哈希，大量使用会导致提交重复，适合少量提交的场景。
stash 是暂存工作区修改，将未提交的代码临时保存，清空工作区，方便切换分支、处理紧急任务。常用命令：git stash 暂存（可加 -m 备注）；git stash list 查看暂存列表；git stash pop 恢复最近暂存并删除；git stash apply 恢复暂存不删除；git stash drop 删除暂存。场景：开发到一半，需要切换分支修复 bug；临时拉取最新代码；处理紧急任务，不想提交半成品代码。stash 不生成提交，轻量安全，是日常开发必备命令。
Tag 是版本标签，标记仓库中固定的提交点，永久指向该版本，不可移动，用于发布版本。常用命令：git tag v1.0.0 创建轻量标签；git tag -a v1.0.0 -m "备注" 创建注解标签；git push origin v1.0.0 推送远程。场景：标记生产发布版本、迭代版本。Tag 与分支区别：Tag固定不可移动，仅标记版本；Branch可移动、可提交，用于持续开发。Tag 是静态的版本标记，Branch 是动态的开发线，两者配合管理版本迭代。
HEAD 是指向当前分支最新提交的指针，表示当前所在的版本；工作目录（Working Directory）是本地编辑代码的文件夹，可见的项目文件；索引（Index/Staging Area）是暂存区，临时存放 git add 后的文件，是工作目录与版本库的中间层。关系：编辑代码→工作目录；git add→存入索引；git commit→提交到版本库，HEAD 移动到新提交。三者构成 Git 的三层架构，是 Git 版本控制的核心机制。
reset 是回退版本，直接移动 HEAD 指针到历史提交，删除后续提交，本地操作，无新提交。分三种模式：--soft（保留代码）、--mixed（默认，保留代码清空暂存）、--hard（删除代码，谨慎使用）。revert 是撤销提交，创建一个新的提交，抵消目标提交的修改，不删除历史提交，安全可推送到远程。reset禁止用于公共分支，会丢失他人提交；revert 适合撤销远程公共分支的提交，安全无风险。
撤销本地最后一次提交：执行 git reset --soft HEAD^，回退到上一版本，保留代码，可重新修改提交。撤销已推送到远程的提交：禁止用 reset，执行 git revert 最新提交哈希，生成撤销提交，再 git push 推送远程，安全不影响他人。若必须重置远程，仅用于个人分支：git reset --hard 目标提交 + git push -f，公共分支严禁强制推送。
删除分支后，可通过提交哈希恢复。步骤：1. 执行 git reflog 查看所有操作记录，找到删除分支前的提交哈希；2. 执行 git checkout 提交哈希，临时进入该提交；3. 执行 git checkout -b 原分支名，基于该提交重建分支。Git 的引用日志会保留 30 天的操作记录，只要未清理仓库，都能恢复删除的分支，无需担心误删丢失代码。
Submodule 是子模块，将一个 Git 仓库作为另一个仓库的子目录，独立管理版本，适合复用公共组件。用法：git submodule add 仓库地址 添加子模块；git clone --recursive 仓库地址 克隆包含子模块的项目；git submodule update 更新子模块。管理：子模块有独立的提交、分支，父仓库仅记录子模块的版本号；修改子模块需进入目录独立提交，父仓库更新引用。适合公共依赖、多项目复用组件的场景。
fetch 是拉取远程仓库最新代码到本地远程分支，不合并、不修改工作区，安全无冲突，可先查看变更再合并。命令：git fetch origin。pull 是fetch + merge 的组合命令，拉取远程代码后，自动合并到当前本地分支，可能产生冲突。命令：git pull origin 分支名。最佳实践：先用 fetch 查看变更，确认无冲突后再 merge，避免自动合并导致代码异常；pull 适合个人分支快速同步。
集中式（SVN）：只有一个中央仓库，所有操作依赖中央服务器，断网无法工作，历史存储在中央，易丢失数据。分布式（Git）：每个开发者本地都是完整仓库，包含所有历史、分支，断网可本地提交、分支、合并，联网后同步远程。Git 速度快、支持分支、安全性高，无单点故障；SVN 简单、适合非代码文件管理。现代开发全部使用 Git，分布式架构更适配团队协作、敏捷开发。
大仓库优化核心：拆分仓库 + 大文件管理。1. 使用Git LFS 插件，将大文件（视频、安装包）存储在独立服务器，Git 仅保留指针，解决大文件拉取慢问题；2. 拆分超大仓库为多个子模块，分模块管理；3. 使用 git shallow clone 浅克隆，仅拉取最新提交，减少历史数据；4. 定期清理历史垃圾文件、大提交；5. 禁用不必要的历史日志。优化后可大幅提升克隆、拉取、提交的速度。
交互式 rebase 用于整理提交历史，合并、修改、删除本地未推送的提交。用法：git rebase -i HEAD~n（n 为需要整理的最近 n 次提交）。进入编辑界面，可选择：pick（保留）、squash（合并到上一个提交）、reword（修改提交信息）、drop（删除提交）。编辑保存后，Git 自动执行整理。适合合并零散的半成品提交，让提交历史整洁规范，仅用于本地未推送的提交。
bisect 是二分查找命令，快速定位引入 bug 的提交。用法：1. 执行 git bisect start 启动；2. 标记当前版本为坏版本 git bisect bad；3. 找到一个历史正常版本，执行 git bisect good 提交哈希；4. Git 自动切换到中间提交，测试是否正常，标记 good/bad；5. 重复操作，Git 快速定位到 bug 引入的提交。适合项目出现 bug，无明确原因时，快速排查问题提交，极大提升排查效率。
Git Hooks 是钩子脚本，在 Git 操作（提交、推送、合并）前后自动执行，实现自动化校验。常用钩子：pre-commit（提交前校验代码格式、语法）、commit-msg（校验提交信息规范）、pre-push（推送前运行单元测试）。无需手动触发，自动拦截不规范代码、未通过测试的提交，避免脏代码提交到仓库。配合 ESLint、单元测试，强制规范开发流程，减少 bug，提升团队协作效率，是企业级开发的标配。
创建远程分支：本地创建分支 git branch 分支名，执行 git push origin 分支名 推送到远程。查看远程分支：git branch -r。切换远程分支：git checkout 分支名（自动关联远程）。删除远程分支：git push origin --delete 分支名。关联本地与远程分支：git branch --set-upstream-to=origin/分支名。远程分支是团队协作的核心，所有功能分支统一推送到远程，共享代码，定期清理废弃远程分支，保持仓库整洁。
查看文件变更历史的常用命令：git log -- 文件名，查看文件的所有提交记录、作者、时间、备注；git log -p -- 文件名，查看文件每次提交的具体代码修改内容；git blame 文件名，逐行显示文件的最后修改人、提交哈希、时间，精准定位每行代码的修改者；git show 提交哈希 -- 文件名，查看指定提交中该文件的修改内容。这些命令可快速追溯文件修改记录，排查 bug、定位修改人。
代码审查（CR）基于分支 +PR/MR 实现。流程：1. 开发者从主分支创建功能分支，开发完成后推送到远程；2. 在 Git 平台（GitHub/GitLab/Gitee）创建 Pull Request/Merge Request，指定审查人；3. 审查人在线查看代码变更，评论、提出修改意见；4. 开发者根据意见修改代码，推送后自动同步到 PR；5. 审查通过后，合并到主分支。CR 可提前发现 bug、规范代码、共享知识，是团队协作的核心环节，Git 原生支持全流程。
Git 基于快照 + 哈希值 实现版本控制。每次执行 git commit，Git 会为当前所有文件创建一个快照，生成唯一的 SHA-1 哈希值标识该版本，而非存储文件差异。Git 本地保存完整的版本历史、分支、提交记录，无需依赖中央服务器。通过指针（HEAD）、分支、暂存区管理版本，支持分支创建、合并、回退，所有操作都是本地执行，速度极快。分布式架构 + 快照机制，让 Git 成为高效、安全、强大的版本控制系统。
