Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
Visual Studio 2019 |Visual Studio 2022
合并或重新设置基时，你告诉 Git 将一个分支上所做的更改与另一个分支上的更改相集成。 通常，Git 会在没有帮助的情况下自动完成合并或重新数据库。 但是，如果 Git 发现一个分支上的更改与另一个分支上的更改冲突，则会提示你解决冲突。 当合并的分支以不同的方式编辑同一文件行时，或者当一个分支修改一个文件和另一个分支删除文件时，可能会发生合并冲突。 解决合并冲突的过程适用于 Git 合并和存储库。
可以在 Visual Studio 中或通过命令行和任何文本编辑器来解决合并冲突。
有关 Git 工作流的概述，请参阅 Azure Repos Git 教程。
先决条件
| 类别 | 要求 |
|---|---|
| 项目访问权限 | 项目的成员。 |
| 权限 | - 查看专用项目中的代码：至少 是基本 访问权限。 - 克隆或参与专用项目中的代码： 参与者 安全组的成员或项目中的相应权限。 - 设置分支或存储库权限： 管理 分支或存储库的权限。 - 更改默认分支： 编辑存储库的策略 权限。 - 导入存储库： 项目管理员 安全组的成员或 Git 项目级 “创建存储库 ”权限设置为 “允许”。 有关详细信息，请参阅 “设置 Git 存储库权限”。 |
| Services | 已启用存储库。 |
| 工具 | 可选。 使用 az repos 命令： Azure DevOps CLI。 |
注释
在公共项目中，具有 利益干系人 访问权限的用户具有对 Azure Repos 的完全访问权限，包括查看、克隆和参与代码。
了解合并冲突
Git 合并或重新数据库将源分支中的提交集成到当前本地分支（目标分支）。 Git 合并 执行 快速转发 或 无快进 合并。 no-fast-forward 合并也称为 三向 合并或 真正的 合并。 Git 存储库 是另一种类型的合并。 下图显示了这些合并类型。
对于 Git 合并，如果目标分支的提示存在于源分支中，则默认合并类型将是快速向前合并。 否则，默认合并类型将是非快速向前合并。
如果目标分支的提示与源分支存在分歧， 则快速转发 合并永远不能发生合并冲突，因为 Git 不会应用快速转发合并。 默认情况下，Git 尽可能使用快速转发合并。 例如，Git 将在仅通过从远程对应分支拉取来更新的本地分支上应用快速向前合并。
无快进合并生成新的目标分支“合并提交”，该分支将源分支更改与目标分支更改集成。 适用的更改是在两个分支共同的最后一次提交之后进行的更改。 在上图中，提交 C 是两个分支中的最后一个常见提交。 如果任何源分支更改都与任何目标分支更改冲突，Git 将提示你解决合并冲突。 合并提交 （L） 包含集成的源分支和目标分支更改。 源和目标分支提示（K 和 E）是合并提交的父级。 在分支的 提交历史记录中，合并提交是合并作的有用标记，并清楚地显示合并了哪些分支。
Git 重新设置 目标分支的提交历史记录，使其包含所有源分支提交，后跟自上次通用提交以来的所有目标分支提交。 在上图中，提交 C 是两个分支中的最后一个常见提交。 另一种查看方法是，在源分支历史记录顶部重播目标分支中的更改。 如果任何源分支更改都与任何目标分支更改冲突，Git 将提示你解决合并冲突。 与快速转发合并一样，存储库不会创建合并提交。 值得注意的是，存储库会更改现有目标分支提交的顺序，而其他合并策略则并非如此。 在上图中，提交 K 包含与 K 相同的更改，但具有新的提交 ID，因为它链接回提交 E 而不是 C。
Git 合并和重新base 仅修改目标分支 - 源分支保持不变。 遇到一个或多个合并冲突时，必须解决这些问题才能完成合并或重新数据库。 或者，可以取消合并/重新base作，并将目标分支返回到其以前的状态。
有关合并选项和策略的详细信息，请参阅 Git 参考手册 和 Git 合并策略。
何时解决合并冲突
Git 合并 和 Git 存储库 在 Git 工作流中广泛使用。 处理本地功能或 bugfix 分支时，通常的做法是：
- 通过定期
main和合并远程提交，使本地分支保持其远程对应项的当前状态。 - 使用存储库或合并将本地
main分支更新集成到本地功能分支。 - 通过将工作 推送 到相应的远程分支来备份本地功能分支上的工作。
- 在功能完成时，创建 拉取请求 ，将远程功能分支合并到远程
main分支中。
通过经常将远程更改集成到本地存储库中，你可以随时了解其他人的最新工作，并及时解决出现的任何合并冲突。
解决合并冲突
解决合并冲突的过程适用于 Git 合并和 Git 存储库。 尽管以下步骤介绍了如何在合并期间解决合并冲突，但可以在重新数据库期间同样解决合并冲突。
Visual Studio 2022 通过使用 Git 菜单、Git 更改以及解决方案资源管理器中的上下文菜单提供 Git 版本控制体验。 Visual Studio 2019 版本 16.8 还提供 团队资源管理器 Git 用户界面。 有关详细信息，请参阅 Visual Studio 2019 - 团队资源管理器 选项卡。
在“Git 存储库”窗口的“分支”窗格中，签出目标分支。 然后右键单击源分支，然后选择“将源分支合并<到>目标分支<>”。
如果 Git 因冲突而停止合并，Visual Studio 将通知你。 在这种情况下，可以解决冲突，也可以取消合并并返回到合并前状态。 “Git 更改”窗口的“未合并更改”部分列出了合并冲突的文件。 对于内容中存在合并冲突的文件，请双击该文件以在合并编辑器中打开它。
在合并编辑器中， “传入 ”窗格显示源分支文件版本、 “当前 ”窗格显示目标分支文件版本，“ 结果 ”窗格显示生成的合并文件。 若要应用特定的源或目标分支更改，请选中要保留的冲突行旁边的复选框。 还可以直接在 “结果 ”窗格中编辑合并文件。 解决当前文件中的所有合并冲突后，选择 “接受合并 ”。 对内容冲突的每个文件重复此步骤。
对于在一个分支中编辑并删除另一个分支的文件，请右键单击该文件并选择所需的分支作。
在“Git 更改”窗口中，输入提交消息，然后选择 “提交暂存 ”以完成合并 — 解决所有文件的所有合并冲突后。
