IDEA如何同时对多个功能进行处理
有时您使用IntelliJ IDEA需要在不完成任务的情况下切换不同的任务，然后返回给他们。IntelliJ IDEA为您提供了几种方式来方便地处理几种不同的功能，并且不会丢失任何需要进行的工作：
- 您可以储藏（stash）或搁置待更改。隐藏的变化与搁置非常相似。唯一的区别在于补丁的生成和应用的方式。Git生成Stahes，可以从IntelliJ IDEA内部或外部应用。具有搁置更改的修补程序由IntelliJ IDEA生成，也通过IDE应用。另外，储藏涉及所有未提交的更改，而当您对搁置架进行更改时，可以选择一些本地更改，而不是将其全部搁置。
- 您可以在不同的更改列表中保留与不同任务或功能相关的更改。
- 您可以创建分支来处理不同的不相关的功能。
搁置改变
搁置暂时存储尚未提交的待处理更改。例如，如果您需要切换到另一个高优先级的任务，并且希望将更改放在一边以便稍后处理，则此方法很有用。
使用IntelliJ IDEA，您可以搁置单独的文件和整个更改列表。
一旦搁置，可以根据需要随时多次更换，然后搁置，然后将其恢复到搁置上。
将更改放到一个架子上
您可以通过选择Changelist（更改列表）下拉菜单，从Shelve Changes（搁置更改）对话框切换到其他更改列表。
- 打开"版本控制工具"窗口（Alt+9）并切换到“本地更改”选项卡。
- 选择要放在架子上的文件或更改列表。在主版本控制菜单或选择的上下文菜单上，选择“搁置更改”。
- 在“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内部或外部创建的修补程序，并将其应用为搁置更改。
- 在版本控制工具窗口的“搁置”选项卡中，从上下文菜单中选择“导入修补程序 ”。
- 在打开的对话框中，选择要应用的修补程序文件。所选修补程序作为一个架子出现在“搁置”选项卡中。
- 选择新添加的带有修补程序的架子，然后从所选内容的上下文菜单中选择Unshelve Changes。
自动搁置基本修改
将IntelliJ IDEA配置为始终搁置Git版本控制下的文件的基本版本可能会很有用。要做到这一点，打开“设置”对话框（Ctrl+Alt+S），选择左边的版本控制|搁置（Version Control | Shelf）节点，并选择"分布式版本控制系统"选项下的文件搁置基础修订。
如果启用此选项，则文件的基本修订将被保存到三路合并期间使用的搁置，如果应用搁置会导致冲突。如果被禁用，IntelliJ IDEA将在项目历史记录中查找基本版本，这可能需要一段时间；此外，有冲突的搁置是基于修改可能会丢失（例如，如果由于基操作而更改了历史记录）。
更改默认的搁置位置
默认情况下，搁置目录位于您的项目目录下。但是，您可能需要更改默认的搁置位置。例如，如果您希望避免在清理工作副本时意外删除搁置，或者希望将其存储在单独的存储库中，以允许在您的团队成员之间共享搁置，这可能很有用。
- 打开“设置”对话框（Ctrl+Alt+S）并选择左侧的：版本控制|搁置节点。
- 单击“更改搁置位置”按钮，然后在打开的对话框中指定新的位置。
- 如有必要，请选择"将搁置移动到新位置"选项以将现有搁置移动到新目录。
储藏（stash）更改
有时可能需要将工作副本恢复为与HEAD提交相匹配，但是您不希望丢失已完成的工作。如果您知道上游的变化可能与您正在做的事情相关，或者您需要做出一些紧急修复，则可能会发生这种情况。
存储涉及记录HEAD提交和工作目录（储藏（stash））的当前状态之间的差异。索引的更改也可以储藏起来。
Unstashing 涉及将存储的储藏处应用到分支。
您可以将储藏应用到现有分支，或者在其基础上创建新的分支。
您可以根据需要多次使用储藏（stash），只需切换到所需的分支即可。请记住：
- 在一系列提交之后应用储藏会导致需要解决的冲突。
- 您不能将存储应用于“不干净（dirty）”工作副本，即具有未提交更改的工作副本。
保存对储藏的更改
- 从主菜单中选择：VCS | Git | 储藏更改。
- 在打开的Stash对话框中，选择适当的Git根并确保签出正确的分支。
- 在“Message”字段中描述您将要储藏的更改。
- 要储藏本地更改，并将索引中的更改提交给工作树进行检查和测试，请选择“保留索引”选项。
- 点击“创建储藏”。
应用一个储藏
要应用储藏，请执行以下操作：
如果有冲突，此操作可能会失败。发生这种情况是因为冲突存储在索引中，因此您无法再将这些更改应用于其原始状态。
- 从主菜单中选择：VCS | Git | Unstash变化。
- 选择您想要应用储藏的Git根，并确保签出正确的分支。
- 从列表中选择您想要应用的储藏。如果要检查选定储藏中的哪些文件受到影响，请单击“查看”。
- 要在应用后删除所选的储藏，选择“弹出储藏”选项。
- 要应用隐藏的索引修改，请选择“恢复索引”选项。
- 如果要基于选定的储藏来创建新分支，而不是将其应用于当前检出的分支，请在“新建分支”字段中键入该分支的名称。
要删除某个储藏，请在列表中选择它，然后单击“删除”。要删除所有的包装，请点击“清除”。
将更改分组到不同的更改列表
当您正在处理几个相关的功能时，可能会发现将更改分组到不同的更改列表中很方便。这种方法有其优点和缺点，而不是使用功能分支来处理多个任务。
优点：
- 您可以轻松地在不同的逻辑集之间进行切换，并将它们彼此分开提交。
- 与使用分支机构来达到同样的目的不同的是，您手头上的所有更改都不需要在分支之间切换，如果您的项目真的很大，则可能需要一段时间。
- 测试不同功能如何协同工作是很方便的。
- 您可以在构建服务器上远程运行更改列表。
缺点：
- 与分支相比，使用更改列表可能看起来更轻量级，但这并不安全，因为除非您提交并推送更改，否则您的更改没有备份。如果您的本地工作副本出现问题，您的所有更改将会丢失，因为它们不属于Git项目历史记录。
- 如果更改不重叠，则只能使用更改列表。如果不同的任务影响同一文件，则不能分开这些更改并将其放入单独的更改列表中。
- 功能的原子测试是不可能的。
- 在同一个功能上合作是不可能的。另外，除非您通过电子邮件发送修改补丁，否则你不能从不同的机器做贡献，这可能不是很方便。
所有更改列表都显示在版本控制工具窗口的“本地更改”选项卡中。所有修改后的文件都会自动放置在活动变更列表中，这是默认的更改列表，除非您创建了另一个变更列表并使其处于活动状态。
要创建一个新的更改列表，请单击工具栏上的
。
要使非默认更改列表处于活动状态，请右键单击该列表并从上下文菜单中选择“设置活动更改列表”。
如果要在更改列表之间移动更改，请选择要移动的文件，然后单击工具栏上的
，或从上下文菜单中选择"移动到其他列表"。
- 如果要使列表与将要丢弃的活动列表的更改一起使用，请选择"设置活动"选项。
- 如果您希望IntelliJ IDEA记住您的上下文，并在编辑器中重新加载当前打开的文件（当此列表变为活动状态时），请选择"跟踪上下文"选项。
您也可以在更改列表之间拖放文件。
使用功能分支
Git中的一个分支代表了一条独立的开发行，所以如果您在准备共享工作结果并将其集成到母版中之前要完成并测试一个独立的功能，则在功能分支中执行它是最好的解决方案。这样可以确保不稳定的代码不会被提交到项目的主代码库中，并且如果需要，您可以轻松地切换到其他任务。
优点：
- 与使用更改列表来分组更改相反，使用功能分支是安全的。在对Git进行更改后，它们将成为Git项目历史记录的一部分，所以即使您损坏了工作树，也可以通过Git reflog来恢复提交 。推送更改后，它们将被备份。
- 您可以开发并行的非相关功能并以原子方式进行测试。
- 当您在分支中完成开发时，您可以重新排序或压缩提交，以便您的历史记录是线性和干净的。
- 在您的功能上进行协作很容易，或者从不同的机器开发它。
缺点：
- 在真正的大型项目上切换分支可能需要时间。
- 将相关特性一起测试并不十分方便。
- 您必须学习使用功能分支并将更改集成到主代码库的工作流。
有两种主要方法可以使用功能分支并将您的更改集成到主代码库中：
- merge选项
- rebase选项
使用合并来集成功能分支中的更改
合并选项的主要优点是完全可追溯性，因为合并到主代码库中的提交保留了其原始哈希和作者，并且属于一个功能的所有提交可以组合在一起。
此工作流适合于将对主代码库的更改涉及请求请求或分层审批过程的项目，因为现有的分支不会以任何方式进行更改。
这种方法的主要缺点是，每次需要合并更改时都会创建无关的合并提交，这严重污染了项目历史并使其难以阅读。
合并选项工作流程涉及以下步骤：
- 为您的单独开发行创建一个分支。
- 在开发过程中提交您的更改。
- 将分支推送到远程存储库。此操作应用于备份，以便您可以从不同的计算机进行协作或工作。
- 当您需要执行与您的功能无关的工作时，请切换到其他分支。
- 检查和测试您的功能，并进行必要的修复。
- 当您准备将工作结果集成到主分支（例如master）时，请执行以下操作：
- 将您的功能分支合并到主代码库中。
- 删除功能分支。
- 推入（push）。
使用rebase来集成来自功能分支的更改
这个选项的主要好处是，您可以得到一个清晰的项目历史，可以使其他人很容易阅读和理解。您的日志不包含merge操作产生的不必要的合并提交，并且您可以获得易于浏览和搜索的线性历史记录。
当决定采用这个工作流程时，您应该记住，rebase重写项目历史记录，因为它为原始功能分支中的每个提交创建新的提交，因此它们将具有不同的哈希，从而妨碍可追溯性。
基础选项涉及以下步骤：
使用您的首字母缩写或昵称（如果它很短）作为您的功能分支名称的前缀是有意义的。通过这种方式，您可以在“分支”菜单中使用“速度搜索”轻松找到所有分支。
- 为您的单独开发行创建一个分支。
- 在开发过程中经常提交您的更改。
- 将分支推送到远程存储库。此操作应用于备份，以便您可以从不同的计算机进行协作或工作。
- 时不时rebase您的功能分支到 master。如果您的功能分支很长，那么这样做才有意义。这有助于：
- 确保您的功能分支和master不相距太远。
- 避免在最终将更改集成到主代码库时解决许多冲突。当您经常重新定义的时候，您可以迭代地解决冲突，而不会最终与长时间的差异进行斗争。
- 加快检查分支，因为分支之间的切换一旦发生充分分歧就会变慢。
- 从远程获取更改，或将更改拖到master分支中。
- rebase您的分支到master。
- 强制将rebase操作的结果推送到您的功能分支。
- 当您需要执行与功能无关的工作时，请切换到master。当您返回到您的功能分支时，请使用rebase进行签出。
- 检查和测试您的功能，并进行必要的修复。
- 当功能完成时，执行交互式rebase。这允许您重新排序和压缩提交，使您的功能分支历史看起来不错，干净。
- 当您准备将工作结果集成到主分支（例如master）时，请执行以下操作：
- 签出master分支。
- 将您的分支与master合并。由于master没有分支，Git会将指针向前移动到功能分支的最新提交，而不是创建新的合并提交（这称为 fast-forward 合并）。
- 删除功能分支。
- 推入（push）。