合并、变基或挑拣以应用更改
在 Git 中，有几种方法可以将一个分支的更改合并到另一个分支中：
合并分支
假设您创建了一个功能分支来处理特定任务，并希望在完成并测试该功能后，将您的工作成果（F1、 F2、 F3 ）集成到主代码库中：
将您的分支 合并 到 main 是最常见的方法。
很常见的是，当您在功能分支上工作时，队友会继续将他们的工作（C4、 C5 ）提交到 main：
当您将功能分支 合并 到 main 时，来自您的功能分支的更改会集成到目标分支的 HEAD：
Git 会创建一个称为合并提交的新提交，该提交是从两条分支分叉点开始，将您的功能分支与 main 的更改合并而成。
合并的主要好处是具备完整的可追溯性，因为合并到 main 代码库中的提交会保留其原始哈希和作者，并且属于同一功能的所有提交都可以归为一组。
这种工作流适用于向 main 代码库提交更改需要经过 Pull Request 或 Merge Request ，或分级审批流程的项目，因为现有分支不会以任何方式被更改。
这种方法的主要缺点是每次需要合并更改时都会创建额外的合并提交，这会严重污染项目历史，使其难以阅读。
合并分支
在 分支 弹出窗口（主菜单 ）或 分支 窗格中的 Git 工具窗口中，选择您想要集成更改的目标分支，并从上下文菜单中选择 签出 以切换到该分支。
请执行以下操作之一：
如果您不需要为合并指定选项，请选择您要合并到当前分支的分支，然后从子菜单中选择 将 <branch_name> 合并到 <target_branch>。
如果您需要指定合并选项，请从主菜单中选择 以打开 合并 对话框：
选择您想合并到当前分支的分支，点击 修改选项 并从以下选项中选择：
--no-ff: 无论何种情况都会创建合并提交，即使该合并可以通过快进解决。--ff-only: 仅在可以快进的情况下才执行合并。--squash: 将在当前分支之上创建一个包含所有拉取更改的单个提交。-m：您将可以编辑合并提交的消息。--no-commit：将执行合并，但不会创建合并提交，以便您可以在提交之前检查合并的结果。--no-verify：执行合并，同时绕过通常默认运行的 pre-merge 和 commit-message 钩子。--allow-unrelated-histories：执行合并，覆盖拒绝在没有共同祖先的情况下合并历史的安全规则。
单击 合并。
如果您的工作树是干净的（意味着您没有未提交的更改），并且功能分支与目标分支之间没有冲突，Git 将合并这两个分支，合并提交将出现在 日志 选项卡中的 Git 工具窗口 Alt+9 中：
如果您的分支与目标分支之间发生冲突，系统会提示您解决这些冲突（请参阅 解决冲突）。 如果合并后仍有未解决的冲突， 合并冲突 节点会出现在 提交 工具窗口 Alt+0 中相应的更改列表里，并附有用于解决它们的链接。
如果您有被合并重写的本地更改，GoLand 会建议执行 智能合并。 如果您选择此选项，GoLand 将 暂存未提交的更改，执行合并，然后取消暂存这些更改。
变基分支（git-rebase）
当您 rebase 一个分支到另一个分支时，您将第一个分支的提交应用到第二个分支的 HEAD 提交之上。
假设您创建了一个功能分支来处理特定任务，并向该分支进行了数次提交（F1、 F2、 F3）：
当您在自己的分支中开发时，队友会继续将他们的工作（C4、 C5 ）提交到 main：
要将队友所做的更改（C4、 C5 ）集成到您的功能分支，您可以将您的分支 变基 到 main 之上。 这样，您会将自己的提交应用到 main 中当前 HEAD 提交之上：
变基的主要好处是，您将获得一个干净的项目历史，便于他人阅读和理解。 您的日志不包含由 merge 操作产生的不必要的合并提交，您将获得易于导航和搜索的线性历史记录。
不过，在决定采用此工作流时，您应牢记， rebase 会重写项目历史记录，因为它会为原始功能分支中的每个提交创建新的提交（F1' 而非 F1 ），因此它们将具有不同的哈希，从而妨碍可追溯性。
将分支变基到另一个分支之上
从主菜单选择
在列表中，选择您要将当前分支变基到的目标分支：
如果您需要从某个特定提交开始变基源分支，而不是变基整个分支，请点击 修改选项 并选择 --onto。
在“源分支”字段中，输入从该提交开始要将当前分支应用到新基线的提交哈希：
如果您要变基的分支当前未检出，请点击 修改选项 ，点击 选择其他分支进行变基 ，随后在出现的列表中选择一个分支：
GoLand 会在开始变基操作之前检出此分支。
根据您的具体情况，从 修改选项 列表中选择其他选项：
--rebase-merges：保留将要变基的提交中的分支结构。请注意，这些合并提交中已解决的合并冲突或手动修改需要手动重新解决或重新应用。
--keep-empty：保留空提交，即相对于其父提交没有任何更改的提交。--root：对分支中可到达的所有提交执行变基。--update-refs：自动强制更新指向正在变基的提交的任何分支。--autosquash：自动压缩标记为 fixup 或 squash 的提交。
单击 变基。
如果您不需要为 rebase 指定选项，您可以在不调用 rebase 对话框的情况下启动 rebase。 在 分支 弹出窗口或 分支窗格中的 Git工具窗口中选择一个分支并执行以下操作之一：
检出并变基到 <current_branch_name> （适用于远程和本地分支）以检出所选分支并将其变基到当前检出的分支之上。 如果远程分支在本地不存在，GoLand 将会静默地创建一个受跟踪的本地分支，切换到该分支并进行变基。
将 <current_branch_name> 变基到 <selected_branch_name> （适用于远程和本地分支）将当前检出的分支变基到所选分支之上。
使用变基拉取到 <current_branch_name> （用于远程分支）以 获取所选分支的更改并在这些更改的基础上变基当前分支。
观看此视频以更好地了解如何执行 rebase 操作：
通过执行交互式变基编辑 Git 历史记录
在 GoLand 的 Git 集成中，您可以通过执行 交互式变基来编辑历史记录，使其线性且有意义。 这使您可以在将功能分支中的更改集成到其他分支之前，通过修改单个提交、更改它们的顺序、将多个提交压缩为一个、跳过包含无关更改的提交等方式来清理提交历史。
编辑当前分支的历史
GoLand 允许您在将更改应用到不同分支之前编辑当前分支的提交历史。
打开 Git 工具窗口 Alt+9 并切换到 日志 选项卡。
将日志过滤为仅显示当前分支的提交：
请选择您要编辑的一系列提交中的最早提交，右键点击它并选择 从此处交互式变基。
该 交互式变基 对话框将显示当前分支中在所选提交之后进行的所有提交的列表：
如果 从此处交互式变基 选项被禁用了，这可能是由于以下原因之一：
所选提交有多个父母
所选提交不在当前分支中
所选提交已推送到 protected branch
若要识别原因，请将鼠标悬停在上下文菜单中的操作上，并查看状态栏中的消息：
您可以对分支记录执行以下更改：
更改应用顺序 ：使用
和 
按钮在列表中上移或下移提交。拣选提交 ：这是所有提交的默认状态。 如果需要撤消您已对某个提交执行的操作，请点击 选取
，使该提交按原样应用。编辑 ：点击 停止并编辑
，这样在开始变基时会在此提交停下，以便进行编辑。当变基在某个提交处暂停时，GoLand 窗口右下角会弹出通知，让您继续或中止变基：
您可以使用上下文操作（例如 还原、 撤销、 修正提交 等），然后再继续变基。 如果您不执行任何操作，此提交将按原样应用。
如果您已关闭该通知，请在主菜单中选择 Git | 继续变基 以继续变基。
重写提交消息 ：点击 改写 或双击某个提交，然后在打开的小型编辑器中编辑文本。
将两个提交合并为一个 ：选择要合并到前一个提交的提交，并点击 合并 ，或点击 合并 按钮旁的箭头，然后选择 修正。
如果您点击 合并 ，默认情况下，这两个提交的消息将被合并，因此如果您不修改生成的提交消息，此操作将反映在分支历史中。
如果您点击 修正 ，将丢弃 fixup 提交的提交消息，因此此更改在分支历史中不可见。
在这两种情况下，应用上述任一操作时，都会打开一个小型编辑器，您可以在其中编辑提交消息。
忽略提交 ：点击 丢弃 ，使所选提交的更改不被应用。
撤消所有更改 ：点击 重置 ，放弃您对这些提交应用的所有操作。
因此， 变基提交 对话框显示了一个图表，说明了您在分支中对提交所执行的所有操作，以便您在开始变基之前进行审查：
单击 开始变基。
编辑分支历史并将其集成到另一个分支
GoLand 允许您将一个分支 变基 到另一个分支之上，并在应用更改之前编辑源分支历史。
从主菜单选择
点击 修改选项 并选择 --interactive。
在列表中，选择您要将当前分支变基到的目标分支：
如果您需要从某个特定提交开始变基源分支，而不是变基整个分支，请点击 修改选项 并选择 --onto。
在“源分支”字段中，输入从该提交开始要将当前分支应用到新基线的提交哈希：
如果您要变基的分支当前未检出，请点击 修改选项 ，点击 选择其他分支进行变基 ，随后在出现的列表中选择一个分支：
GoLand 会在开始变基操作之前检出此分支。
根据您的具体情况，从 修改选项 列表中选择其他选项：
--rebase-merges：保留将要变基的提交中的分支结构。请注意，这些合并提交中已解决的合并冲突或手动修改需要手动重新解决或重新应用。
--keep-empty：保留空提交，即相对于其父提交没有任何更改的提交。--root：对分支中可到达的所有提交执行变基。--update-refs：自动强制更新指向正在变基的提交的任何分支。--autosquash：自动压缩标记为 fixup 或 squash 的提交。
单击 变基。
交互式变基 对话框将显示包含当前分支中所有在所选提交之后进行的提交列表。
您可以对分支记录执行以下更改：
更改应用顺序 ：使用
和 按钮在列表中上移或下移提交。拣选提交 ：这是所有提交的默认状态。 如果需要撤消您已对某个提交执行的操作，请点击 选取
，使该提交按原样应用。编辑 ：点击 停止并编辑
，这样在开始变基时会在此提交停下，以便进行编辑。当变基在某个提交处暂停时，GoLand 窗口右下角会弹出通知，让您继续或中止变基：
您可以使用上下文操作（例如 还原、 撤销、 修正提交 等），然后再继续变基。 如果您不执行任何操作，此提交将按原样应用。
如果您已关闭该通知，请在主菜单中选择 Git | 继续变基 以继续变基。
重写提交消息 ：点击 改写 或双击某个提交，然后在打开的小型编辑器中编辑文本。
将两个提交合并为一个 ：选择要合并到前一个提交的提交，并点击 合并 ，或点击 合并 按钮旁的箭头，然后选择 修正。
如果您点击 合并 ，默认情况下，这两个提交的消息将被合并，因此如果您不修改生成的提交消息，此操作将反映在分支历史中。
如果您点击 修正 ，将丢弃 fixup 提交的提交消息，因此此更改在分支历史中不可见。
在这两种情况下，应用上述任一操作时，都会打开一个小型编辑器，您可以在其中编辑提交消息。
忽略提交 ：点击 丢弃 ，使所选提交的更改不被应用。
撤消所有更改 ：点击 重置 ，放弃您对这些提交应用的所有操作。
因此， 变基提交 对话框显示了一个图表，说明了您在分支中对提交所执行的所有操作，以便您在开始变基之前进行审查：
单击 开始变基。
挑选单独提交
有时候，您只需要将单个 commit 应用到不同的分支，而不是重新调整基底或合并整个分支。 例如，如果您正在功能分支中工作，并希望集成在两条分支分叉之后提交到 main 的热修复，这可能会很有用。 或者您可能希望将修复程序移植到先前的发布分支。 您可以通过使用 拣选 操作来完成此操作。
cherry-pick 操作的状态显示在状态栏中。 您始终可以通过在 中止优选 弹出窗口中选择 Git 分支 来中止正在进行的 cherry-pick。
将提交应用到另一个分支
在 分支 弹出窗口（主菜单 ）中，选择您要将更改集成到的目标分支，并在弹出菜单中选择 签出 以切换到该分支。
打开 Git 工具窗口 Alt+9 并切换到 日志 选项卡。
找到包含您想要 cherry-pick 的更改的提交。
您可以按分支、用户或日期过滤提交。 您还可以点击工具栏上的
，并选择 高亮 | 未选择的提交 选项，将已应用到当前分支的提交变灰显示。 如果您知道提交哈希，或正在查找带标签的提交，也可以使用 转到哈希/分支/标签 操作（在 Git 工具窗口 Alt+9 的 日志 选项卡中按 Ctrl+F ，或单击工具栏上的 
）。选择所需的提交。 请使用 提交详细信息 区域中的信息来确认这些是您想要转移到另一个分支的更改。
请点击 拣选
工具栏。 GoLand 将对目标分支应用并提交更改。如果 cherry-pick 因冲突而失败，所选更改将出现在 提交 工具窗口 Alt+0 中的 更改 区域 . 您可以稍后查看这些更改并在必要时提交。
如果您希望 GoLand 在 cherry-pick 失败时自动创建变更列表，请在 中开启相应的设置。
将更改推送到目标分支。
以下视频将帮助您了解 cherry-pick 的工作原理：
应用单独更改
设想您对一个文件进行了更改，并希望将这些更改应用到另一个分支，但这些更改与其他修改的文件一起被提交了。 GoLand 允许您将单独的更改应用到变更列表，而无需立即提交，而不是拣选整个提交。
在 分支 弹出窗口（主菜单 ）中，选择您要将更改集成到的目标分支，并在弹出菜单中选择 签出 以切换到该分支。
打开 Git 工具窗口 Alt+9 并切换到 日志 选项卡。
找到包含您想应用的更改的提交。
您可以按分支、用户或日期过滤提交。 您还可以点击工具栏上的
，并选择 高亮 | 未选择的提交 选项，将已应用到当前分支的提交变灰显示。 如果您知道提交哈希，或正在查找带标签的提交，也可以使用 转到哈希/分支/标签 操作（在 Git 工具窗口 Alt+9 的 日志 选项卡中按 Ctrl+F ，或单击工具栏上的 ）。在右侧的 提交详细信息 窗格中，选择包含您要应用到目标分支的更改的文件，并从上下文菜单中选择 拣选所选更改。
在打开的对话框中，选择一个现有的 changelist 或输入一个新 changelist 的名称，然后点击 确定。
提交更改，然后将其推送到目标分支。
应用独立文件
除了对单个文件应用单独的更改，您还可以将整个文件的内容复制到不同的分支。 例如，如果您想应用的文件在目标分支中不存在，或其变更是在多个提交中进行的，这可能会很有用。
。