处理多个功能

有时您使用IntelliJ IDEA需要在不完成任务的情况下切换不同的任务，然后返回给他们。IntelliJ IDEA为您提供了几种方式来方便地处理几种不同的功能，并且不会丢失任何需要进行的工作：

搁置改变

搁置暂时存储尚未提交的待处理更改。例如，如果您需要切换到另一个高优先级的任务，并且希望将更改放在一边以便稍后处理，则此方法很有用。

使用IntelliJ IDEA，您可以搁置单独的文件和整个更改列表。

一旦搁置，可以根据需要随时多次更换，然后搁置，然后将其恢复到搁置上。

将更改放到一个架子上

您可以通过选择Changelist（更改列表）下拉菜单，从Shelve Changes（搁置更改）对话框切换到其他更改列表。

为避免多个搁置同名（例如Default），您可以简单地将文件或更改列表从“本地更改”选项卡拖放到“搁置”选项卡，等待一秒钟，直到它被激活，并在释放鼠标按钮时即时编辑新的搁置名称。

也可以在不显示"搁置更改"对话框的情况下，静默地搁置更改。为此，请选择要搁置的文件或更改列表，然后单击工具栏上的Shelve Silently图标 ，或按 Ctrl+Alt+H。包含您要搁置的更改的更改列表的名称将用作货架名称。

取消搁置更改

不负责任的是将推迟的更改从搁架移动到待处理的更改列表。未保存的更改可以从视图中滤除或从货架上移除。

	在“版本控制工具”窗口的“货架”选项卡中，选择要取消搁置的更改列表或文件。
	按下Ctrl+Shift+U或从选择的上下文菜单中选择Unshelve。
	在打开的“Unshelve Changes”对话框中，在“Name”字段中指定要更改未保存更改的更改列表。您可以从下拉列表中选择一个现有变更列表，或为包含未保存变更的新变更列表输入名称。您可以在“Comment”字段中输入新变更列表的描述（可选）。如果要使新的更改列表处于活动状态，请选择"设置活动"选项。否则，当前活动的更改列表保持活动状态。
	如果您希望IntelliJ IDEA在停用时保留与新变更列表关联的任务的上下文并恢复上下文，那么使变更列表变为活动状态，请选择“追踪上下文”选项（请参阅“管理任务和上下文”以了解详细信息）。
	如果要删除要取消搁置的更改，请选择：从搁置选项中删除已成功应用的文件。未搁置的文件将被从这个架子上移除，并被添加到另一个更改列表中并标记为已应用。直到通过单击工具栏上的 图标或从上下文菜单中选择“清除已取消未保存的内容”，它们才会完全删除。
	点击“确定”。如果修补版本和当前版本之间发生冲突，请按照“解决冲突”中的说明解决它们 。

您还可以将文件或更改列表从“搁置”选项卡拖放到“本地更改”选项卡，以静默取消搁置。

您也可以静默地取消保存更改，而不显示“Unshelve Changes”对话框。为此，请选择要取消搁置的文件或更改列表，然后单击工具栏上的“取消搁置无图标”图标 ，或按 Ctrl+Alt+U。未保存的文件将被移动到活动挂起更改列表。

还原未保存的更改

IntelliJ IDEA可以让您在必要时重新应用未保存的更改。所有未保存的更改都可以重复使用，直到通过单击工具栏上的 图标或从上下文菜单中选择“清除已取消未保存的内容”以显式删除它们。

要恢复货架上应用的更改，请执行以下操作：

	确保已启用显示已取消搁置的工具栏选项
	选择要还原的文件或货位。
	在选择的上下文菜单上，选择还原。

应用外部补丁

您可以导入在IntelliJ IDEA内部或外部创建的修补程序，并将其应用为搁置更改。

自动搁置基本修改

将IntelliJ IDEA配置为始终搁置Git版本控制下的文件的基本版本可能会很有用。要做到这一点，打开“设置”对话框（Ctrl+Alt+S），选择左边的版本控制|搁置（Version Control | Shelf）节点，并选择"分布式版本控制系统"选项下的文件搁置基础修订。

如果启用此选项，则文件的基本修订将被保存到三路合并期间使用的搁置，如果应用搁置会导致冲突。如果被禁用，IntelliJ IDEA将在项目历史记录中查找基本版本，这可能需要一段时间；此外，有冲突的搁置是基于修改可能会丢失（例如，如果由于基操作而更改了历史记录）。

更改默认的搁置位置

默认情况下，搁置目录位于您的项目目录下。但是，您可能需要更改默认的搁置位置。例如，如果您希望避免在清理工作副本时意外删除搁置，或者希望将其存储在单独的存储库中，以允许在您的团队成员之间共享搁置，这可能很有用。

储藏（stash）更改

有时可能需要将工作副本恢复为与HEAD提交相匹配，但是您不希望丢失已完成的工作。如果您知道上游的变化可能与您正在做的事情相关，或者您需要做出一些紧急修复，则可能会发生这种情况。

存储涉及记录HEAD提交和工作目录（储藏（stash））的当前状态之间的差异。索引的更改也可以储藏起来。

Unstashing 涉及将存储的储藏处应用到分支。

您可以将储藏应用到现有分支，或者在其基础上创建新的分支。

您可以根据需要多次使用储藏（stash），只需切换到所需的分支即可。请记住：

保存对储藏的更改

应用一个储藏

要应用储藏，请执行以下操作：

如果有冲突，此操作可能会失败。发生这种情况是因为冲突存储在索引中，因此您无法再将这些更改应用于其原始状态。

要删除某个储藏，请在列表中选择它，然后单击“删除”。要删除所有的包装，请点击“清除”。

将更改分组到不同的更改列表

当您正在处理几个相关的功能时，可能会发现将更改分组到不同的更改列表中很方便。这种方法有其优点和缺点，而不是使用功能分支来处理多个任务。

优点：

缺点：

所有更改列表都显示在版本控制工具窗口的“本地更改”选项卡中。所有修改后的文件都会自动放置在活动变更列表中，这是默认的更改列表，除非您创建了另一个变更列表并使其处于活动状态。

要创建一个新的更改列表，请单击工具栏上的 。

要使非默认更改列表处于活动状态，请右键单击该列表并从上下文菜单中选择“设置活动更改列表”。

如果要在更改列表之间移动更改，请选择要移动的文件，然后单击工具栏上的 ，或从上下文菜单中选择"移动到其他列表"。

您也可以在更改列表之间拖放文件。

使用功能分支

Git中的一个分支代表了一条独立的开发行，所以如果您在准备共享工作结果并将其集成到母版中之前要完成并测试一个独立的功能，则在功能分支中执行它是最好的解决方案。这样可以确保不稳定的代码不会被提交到项目的主代码库中，并且如果需要，您可以轻松地切换到其他任务。

优点：

缺点：

有两种主要方法可以使用功能分支并将您的更改集成到主代码库中：

• merge选项
• rebase选项

使用合并来集成功能分支中的更改

合并选项的主要优点是完全可追溯性，因为合并到主代码库中的提交保留了其原始哈希和作者，并且属于一个功能的所有提交可以组合在一起。

此工作流适合于将对主代码库的更改涉及请求请求或分层审批过程的项目，因为现有的分支不会以任何方式进行更改。

这种方法的主要缺点是，每次需要合并更改时都会创建无关的合并提交，这严重污染了项目历史并使其难以阅读。

合并选项工作流程涉及以下步骤：

使用rebase来集成来自功能分支的更改

这个选项的主要好处是，您可以得到一个清晰的项目历史，可以使其他人很容易阅读和理解。您的日志不包含merge操作产生的不必要的合并提交，并且您可以获得易于浏览和搜索的线性历史记录。

当决定采用这个工作流程时，您应该记住，rebase重写项目历史记录，因为它为原始功能分支中的每个提交创建新的提交，因此它们将具有不同的哈希，从而妨碍可追溯性。

基础选项涉及以下步骤：

使用您的首字母缩写或昵称（如果它很短）作为您的功能分支名称的前缀是有意义的。通过这种方式，您可以在“分支”菜单中使用“速度搜索”轻松找到所有分支。

为您的单独开发行创建一个分支。

在开发过程中经常提交您的更改。

将分支推送到远程存储库。此操作应用于备份，以便您可以从不同的计算机进行协作或工作。

时不时rebase您的功能分支到 master。如果您的功能分支很长，那么这样做才有意义。这有助于：

重新激活涉及以下步骤：

当您需要执行与功能无关的工作时，请切换到master。当您返回到您的功能分支时，请使用rebase进行签出。

检查和测试您的功能，并进行必要的修复。

当功能完成时，执行交互式rebase。这允许您重新排序和压缩提交，使您的功能分支历史看起来不错，干净。

当您准备将工作结果集成到主分支（例如master）时，请执行以下操作：