18-Git

Merge 结果：
main:    A — B — C — D
               \
feature:        E — F — M   (M 是合并提交)

Rebase 结果：
main:    A — B — C — D — E' — F'
feature:               /
        (E' 和 F' 是新提交，哈希值与 E、F 不同)

1. 切换到目标分支（如 main）：git checkout main
2. 执行合并：git merge feature
3. Git 找到两个分支的最近公共祖先（Merge Base）
4. 进行三方合并：
   a. 找到公共祖先提交
   b. 比较两个分支相对于公共祖先的差异
   c. 将两个差异合并到公共祖先基础上
5. 如果没有冲突，创建合并提交（有两个父提交）
6. 如果有冲突，标记冲突文件，等待手动解决

1. 切换到特性分支：git checkout feature
2. 执行变基：git rebase main
3. Git 执行以下操作：
   a. 找到 feature 分支相对于 main 的 Merge Base
   b. 将 feature 分支上从 Merge Base 之后的每个提交"摘下来"
   c. 在 main 的最新提交之上，逐个重新应用这些提交
   d. 每个重新应用的提交会产生新的 commit（新的哈希值）
4. 如果有冲突：
   a. 暂停 rebase 过程
   b. 标记冲突文件
   c. 手动解决冲突
   d. 执行 git add <file>
   e. 执行 git rebase --continue 继续
   f. 或 git rebase --abort 放弃 rebase

# 标准合并流程
git checkout main
git pull origin main          # 拉取最新 main
git merge feature/login       # 合并特性分支
# 如果有冲突，解决后：
# git add .
# git commit -m "解决合并冲突"
git push origin main

# 压缩合并（Squash Merge）：将特性分支所有提交压缩为一个
git checkout main
git merge --squash feature/login
git commit -m "feat: 实现登录功能"

# 在特性分支上整理提交历史
git checkout feature/login
git fetch origin
git rebase origin/main        # 将特性分支变基到最新 main

# 如果有冲突：
# 解决冲突
# git add .
# git rebase --continue

# 交互式 rebase：合并/重排/修改提交
git rebase -i HEAD~3          # 变基最近 3 个提交
# 在编辑器中修改：
# pick abc1234 feat: 添加登录接口
# squash def5678 fix: 修复密码校验
# reword ghi9012 feat: 重写提交信息

# 推送变基后的分支（需要 force push）
git push --force-with-lease origin feature/login

# 推荐工作流：特性分支开发 → 变基整理 → 合并到 main

# 1. 创建特性分支
git checkout -b feature/payment main

# 2. 开发过程中，定期同步 main 的最新进度
git fetch origin
git rebase origin/main

# 3. 开发完成后，整理提交历史
git rebase -i origin/main
# 将多个提交压缩为 2-3 个有意义的提交

# 4. 推送到远程
git push origin feature/payment

# 5. 创建 Pull Request（代码审查）
# 在 GitLab/GitHub 上创建 PR

# 6. 审查通过后，使用 Squash Merge 或 Merge Commit 合入
# Squash Merge: 将 PR 所有提交压缩为一个
# Merge Commit: 保留完整分支历史

是否需要保留完整历史？
  ├── 是 → 使用 Merge
  └── 否 → 分支是否已推送到远程？
              ├── 是 → 使用 Merge（已共享的分支）
              └── 否 → 使用 Rebase 整理后合并

git push --force-with-lease origin feature/branch
# --force-with-lease 比 --force 更安全，会检查远程分支是否有他人的新提交

git rebase --abort    # 放弃 rebase，回到 rebase 前的状态
git rebase --skip     # 跳过当前有冲突的提交

git reflog                      # 查看 HEAD 的移动历史
git checkout <old-commit-hash>  # 检出旧提交
git branch recovery-branch <hash>  # 从旧提交创建恢复分支

1. 使用 IDE 的 Git 冲突解决工具（IntelliJ IDEA、VS Code 都有可视化工具）
2. 理解冲突标记：
   <<<<<<< HEAD          ← 当前分支内容
   当前分支的代码
   =======               ← 分隔线
   待合并分支的代码
   >>>>>>> feature       ← 目标分支内容
3. 手动编辑文件解决冲突
4. git add <resolved-file>
5. git commit 完成合并

<<<<<<< HEAD
当前分支的修改内容（当前分支 = main）
=======
待合并分支的修改内容（待合并分支 = feature）
>>>>>>> feature

Merge Base（公共祖先）: A
Branch 1（当前）:       A → B（修改了第 5-8 行）
Branch 2（待合并）:     A → C（修改了第 5-8 行）

三方合并尝试：
  对 Branch 1：Base → B 的差异是修改第 5-8 行
  对 Branch 2：Base → C 的差异是修改第 5-8 行
  两个差异作用于同一区域 → 冲突！

1. 执行合并操作：git merge feature
2. Git 检测冲突，输出：
   Auto-merging src/main.java
   CONFLICT (content): Merge conflict in src/main.java
   Automatic merge failed; fix conflicts and then commit the result.
3. git status 查看冲突文件列表
4. 打开每个冲突文件，理解修改意图
5. 手动编辑，保留正确代码
6. git add <resolved-file>
7. 所有文件解决后，git commit 完成合并
8. git push 推送到远程

1. git rebase main
2. Git 应用每个提交时检测冲突
3. 解决冲突（同上）
4. git add <resolved-file>
5. git rebase --continue 继续下一个提交
6. 重复直到所有提交应用完成
7. 如果想放弃：git rebase --abort

# 1. 查看冲突
git status
# Unmerged paths:
#   (use "git add/..." to mark resolution)
#        both modified:   src/main/java/com/example/UserService.java

# 2. 打开文件，看到冲突标记
cat src/main/java/com/example/UserService.java
# <<<<<<< HEAD
# public User getUser(Long id) {
#     return userRepository.findById(id);
# }
# =======
# public User getUser(Long id) {
#     User user = userRepository.findById(id);
#     if (user == null) {
#         throw new UserNotFoundException(id);
#     }
#     return user;
# }
# >>>>>>> feature

# 3. 理解：当前分支做了简化，特性分支增加了空值检查
# 决定保留特性分支的版本（更完善），删除冲突标记

# 4. 编辑后的文件：
# public User getUser(Long id) {
#     User user = userRepository.findById(id);
#     if (user == null) {
#         throw new UserNotFoundException(id);
#     }
#     return user;
# }

# 5. 标记解决
git add src/main/java/com/example/UserService.java

# 6. 完成合并
git commit -m "解决合并冲突，保留空值检查逻辑"

# 使用 merge 工具（需要配置）
git mergetool

# 配置默认 merge 工具
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd "code --wait $MERGED"

# 或使用图形化工具
git gui              # Git 自带 GUI
git mergetool --tool=meld  # 使用 Meld

# 1. 频繁同步 main 分支
git checkout feature
git fetch origin
git merge origin/main    # 或 git rebase origin/main

# 2. 使用 .gitattributes 设置合并策略
# 在项目根目录创建 .gitattributes 文件
# 指定某些文件的合并策略
*.java merge=java        # 使用 Java 感知的合并
*.xml merge=xml          # 使用 XML 感知的合并
*.json merge=json        # 使用 JSON 感知的合并

# 3. 使用 Git Hooks 进行预提交检查
# 在 .git/hooks/pre-commit 中添加检查

1. 打开冲突文件，IDEA 自动高亮冲突区域
2. 点击冲突标记上方的按钮：
   - Accept Current:  接受当前分支版本
   - Accept Incoming: 接受待合并分支版本
   - Accept Both:     接受两个版本
3. 或直接手动编辑
4. Ctrl+Alt+M（或 VCS → Git → Resolve Conflicts）
5. 选择 "Merge" 完成冲突解决

# 整个合并过程中冲突都采用对方版本
git merge -X theirs feature

# 单个文件采用对方版本
git checkout --theirs src/main.java
git add src/main.java

# 方案一：逐个解决（推荐，保证正确性）
git rebase main
# 解决第一个提交的冲突
git add .
git rebase --continue
# 解决第二个提交的冲突
# ... 重复

# 方案二：跳过有问题的提交
git rebase main
git rebase --skip     # 跳过当前提交

# 方案三：中止 rebase，改用 merge
git rebase --abort
git checkout main
git merge feature

# 选择保留当前版本
git checkout --ours path/to/binary-file
git add path/to/binary-file
git commit

# 或保留对方版本
git checkout --theirs path/to/binary-file
git add path/to/binary-file
git commit

# 使用 git 命令逐个处理二进制文件冲突
git diff --name-only --diff-filter=U  # 列出所有冲突文件

# 配置 .gitattributes 统一行尾
* text=auto eol=lf    # 所有文件使用 LF 行尾

# 使用 merge driver 处理格式
git config --global merge.ignorcr.driver \
    "true"  # 忽略 CRLF 冲突

# 重新合并
git merge --abort     # 放弃当前合并，回到合并前状态
git rebase --abort     # 放弃当前 rebase

# 手动重置文件
git checkout --conflict=merge <file>  # 恢复冲突标记

模式：所有开发者在一个中央仓库的 main 分支上直接提交
分支模型：只有 main 分支
适用场景：单人开发、小团队、从 SVN 迁移的项目

流程：
  开发者 A ──push──→ main ←──push── 开发者 B
                ↓
             中央仓库

# 基本操作
git clone <repo-url>        # 克隆仓库
git checkout main
git pull origin main        # 拉取最新
# ... 开发 ...
git add .
git commit -m "feat: xxx"
git pull --rebase origin main  # 拉取并变基
git push origin main          # 推送

模式：每个新功能在独立分支上开发，完成后合并到 main
分支模型：main（主干）+ feature/*（特性分支）
适用场景：小型团队，快速迭代

流程：
  main: ──A──B──C──D──E
                \
  feature/login:  F──G──H
                    \
                  merge → main

git checkout main
git pull origin main
git checkout -b feature/login        # 创建特性分支
# ... 开发 ...
git add .
git commit -m "feat: 添加登录接口"
git push -u origin feature/login     # 推送到远程
# 创建 Pull Request → Code Review → 合并
git checkout main
git pull origin main
git branch -d feature/login          # 删除已合并的分支

模式：最完整的分支模型，包含 5 类分支
分支模型：
  - main:       生产环境代码
  - develop:    开发集成分支
  - feature/*:  特性分支（从 develop 创建）
  - release/*:  发布分支（从 develop 创建）
  - hotfix/*:   紧急修复（从 main 创建）

适用场景：版本驱动的项目（如 App、库、中间件）

                    ┌── feature/A ──┐
                    │               │
  develop: ─────────┤               ├───────
                    │               │
                    └── feature/B ──┘
                            │
                    ┌── release/1.0 ──┐
                    │                 │
  main: ────────────┤                 ├───
                    │                 │
                    └── hotfix/1.0.1 ──┘

# 创建特性分支
git checkout develop
git checkout -b feature/user-auth

# 创建发布分支
git checkout develop
git checkout -b release/1.0.0
# 在发布分支上进行测试和 bugfix
# 合并到 main（发布）和 develop（同步）
git checkout main
git merge release/1.0.0
git checkout develop
git merge release/1.0.0
git branch -d release/1.0.0

# 创建紧急修复
git checkout main
git checkout -b hotfix/1.0.1
# 修复 bug 并测试
git checkout main
git merge hotfix/1.0.1
git checkout develop
git merge hotfix/1.0.1

模式：简化版，基于主干开发 + Pull Request
分支模型：main（主干）+ feature/*（特性分支）
核心规则：
  1. main 分支始终可部署
  2. 所有开发在特性分支上进行
  3. 特性分支通过 Pull Request 合并
  4. Code Review 通过后才能合并
  5. 合并后立即部署

适用场景：持续交付的互联网产品

main: ──A──B──C──D──E──F──G
                  \
  feature/payment:  H──I──J
                    ↓
              Pull Request
                    ↓
              Code Review
                    ↓
              Merge → main → 部署

# 开发流程
git checkout main
git pull origin main
git checkout -b feature/payment-api

# 开发过程中同步 main
git fetch origin
git rebase origin/main

# 提交并推送
git add .
git commit -m "feat: 添加支付接口"
git push -u origin feature/payment-api

# 在 GitHub/GitLab 上创建 PR
# 指定 Reviewer 进行 Code Review
# CI/CD 自动运行测试
# 审查通过后合并到 main
# 自动部署到生产环境

模式：每个开发者 fork 中央仓库，在自己的 fork 中开发，通过 PR 贡献代码
分支模型：中央仓库（upstream）+ 个人 fork（origin）
适用场景：开源项目、多团队协作、不信任的贡献者

中央仓库（upstream）: main
    ↑
    │ Pull Request
    │
个人 fork（origin）: feature/*

# 1. Fork 中央仓库（通过 GitHub/GitLab 网页操作）
# 2. 克隆个人 fork
git clone <personal-fork-url>
cd project
git remote add upstream <central-repo-url>

# 3. 同步中央仓库
git fetch upstream
git checkout main
git merge upstream/main

# 4. 创建特性分支
git checkout -b feature/new-feature

# 5. 推送到个人 fork
git push origin feature/new-feature

# 6. 创建 Pull Request 到中央仓库
# 在 GitHub/GitLab 上操作

命名规范：
  - main:           生产环境
  - develop:        开发环境（可选，小团队可省略）
  - feature/xxx:    特性分支（从 main 创建）
  - hotfix/xxx:     紧急修复（从 main 创建）

合并策略：
  - 一律通过 Merge Request / Pull Request
  - 必须至少 1 人 Code Review
  - CI/CD 必须通过
  - 使用 Squash Merge 保持提交整洁

发布流程：
  1. 开发者创建 feature 分支
  2. 开发完成后提 MR
  3. Reviewer 审查并通过
  4. CI 自动运行测试
  5. 合并到 main
  6. 自动部署到预发/生产

feature/       # 新功能：feature/payment-integration
bugfix/        # Bug 修复：bugfix/login-timeout
hotfix/        # 紧急修复：hotfix/payment-crash
release/       # 发布版本：release/v2.1.0
docs/          # 文档：docs/api-reference
refactor/      # 重构：refactor/user-service

## 变更描述
<!-- 简要描述本次变更的目的和内容 -->

## 变更类型
- [ ] 新功能
- [ ] Bug 修复
- [ ] 重构
- [ ] 文档

## 关联 Issue
<!-- 关联的 Issue 编号 -->

## 测试验证
<!-- 描述如何测试和验证本次变更 -->

## 截图（如果适用）

团队规模？
  ├── 1 人 → 集中式
  ├── 2-10 人 → 是否需要版本管理？
  │   ├── 是 → Git Flow
  │   └── 否 → GitHub Flow
  └── 10+ 人 → 是否持续交付？
      ├── 是 → GitHub Flow + 特性分支
      └── 否 → Git Flow

# 方案：定期同步 main
git checkout feature/a
git fetch origin
git rebase origin/main

# 如果特性 A 和 B 有依赖关系：
# 先开发 A，合并到 main，再让 B 基于最新 main 开发
# 或 B 从 A 分支创建（基于 A 的提交继续开发）
git checkout feature/a
git checkout -b feature/b