使用 Git 同时处理多个功能
有时，您需要在未完成的事情之间切换不同的任务，然后再返回它们。WebStorm 为您提供了几种方法来方便地处理几种不同的功能，而不会丢失您的工作：
存储更改与搁置非常相似。唯一的区别在于生成和应用补丁的方式。存储由 Git 生成，可以在 WebStorm 内部或外部应用。带有搁置更改的补丁由 WebStorm 生成，也通过 IDE 应用。此外，存储涉及所有未提交的更改，而当您将更改放到架子上时，您可以选择一些本地更改而不是全部搁置。
您可以创建分支来处理不同的不相关功能。
搁置更改
搁置临时存储您尚未提交的待处理更改。这很有用，例如，如果您需要切换到另一个任务，并且您想将所做的更改放在一边以便以后处理它们。
使用 WebStorm，您可以搁置单独的文件和整个变更列表。
搁置后，可以根据需要多次应用更改。
搁置更改
在“ 提交工具”窗口Alt+0中，右键单击要放入搁架的文件或更改列表，然后从上下文菜单中选择搁置更改。
在“搁置更改”对话框中，查看已修改文件的列表。
在Commit Message字段中，输入要创建的架子的名称，然后单击Shelve Changes按钮。
您也可以静默搁置更改，而不显示搁置更改对话框。为此，请选择要搁置的文件或更改列表，然后单击工具栏上的静默搁置图标
，或按Ctrl+Shift+H。包含您要搁置的更改的更改列表的名称将用作搁架名称。
为避免出现许多同名的架子（例如Default），您可以将文件或更改列表从Local Changes视图拖到Shelf选项卡，等待一秒钟直到它被激活，然后编辑新架子释放鼠标按钮时即时命名。
取消搁置更改
取消搁置是将推迟的更改从架子移到待处理的更改列表。未搁置的更改可以从视图中过滤掉或从搁架中删除。
在“搁置”选项卡中，选择更改列表或要取消搁置的文件。
按下Ctrl+Shift+U或从所选内容的上下文菜单中选择取消搁置。
在Unshelve Changes对话框中，在Name字段中指定要将未搁置的更改恢复到的更改列表。您可以从列表中选择现有更改列表，或输入要创建的包含未搁置更改的新更改列表的名称。您可以在Comment字段中输入新更改列表的描述（可选）。
如果要使新的更改列表处于活动状态，请选择Set active。否则，当前活动的更改列表保持活动状态。
如果您希望 WebStorm 在停用时保留与新更改列表关联的任务的上下文，并在更改列表变为活动状态时恢复上下文，请选择跟踪上下文选项（有关详细信息，请参阅任务和上下文）。
如果要删除您将要取消搁置的更改，请选择从搁架中删除成功应用的文件选项。未搁置的文件将从该搁架中删除并添加到另一个更改列表并标记为已应用。
在通过单击工具栏或从上下文菜单中选择Clean Already Unshelved明确删除之前，它们不会被完全删除。单击确定。如果修补版本和当前版本之间发生冲突，请按照解决冲突中的说明解决。
您也可以静默取消搁置更改，而不显示“取消搁置更改”对话框。为此，请选择要取消搁置的文件或更改列表，然后单击工具栏上的Unshelve Silently图标
，或按Ctrl+Alt+U。未搁置的文件将被移动到活动的挂起更改列表。
您还可以将文件或更改列表从Shelf选项卡拖到Local Changes视图以静默地取消搁置它。如果您按住Ctrl键拖动它，它将被复制到“本地更改”选项卡，而不是从架子上删除。
放弃搁置的更改
在书架视图中，选择包含您不想再保留的更改的更改列表。
右键单击它并从上下文菜单中选择删除Delete，或按。
恢复未搁置的更改
WebStorm 允许您在必要时重新应用未搁置的更改。所有未搁置的更改都可以重复使用，直到通过单击工具栏上的图标或从上下文菜单中选择Clean Already Unshelved明确删除它们。
确保启用了“显示已搁置”工具栏选项。
选择要恢复的文件或架子。
从选择的上下文菜单中，选择恢复。
应用外部补丁
您可以导入在 WebStorm 内部或外部创建的补丁，并将它们作为搁置的更改应用。
在Shelf视图中，从上下文菜单中选择Import Patches 。
在打开的对话框中，选择要应用的补丁文件。选定的 Patch 在Shelf选项卡中显示为一个架子。
选择带有补丁的新添加的架子，然后从选择的上下文菜单中选择取消搁置更改。
自动搁置基础修订
将 WebStorm 配置为始终搁置受 Git 版本控制的文件的基本修订可能很有用。
按Ctrl+Alt+S打开 IDE 设置并选择版本控制 | 架子。
选择在分布式版本控制系统下搁置文件的基本修订选项。
如果启用此选项，则文件的基本修订版将保存到一个架子中，如果应用架子导致冲突，该架子将在3 路合并期间使用。如果禁用，WebStorm 将在项目历史中查找基础修订，这可能需要一段时间；此外，冲突货架所基于的修订可能会丢失（例如，如果历史记录因变基操作而更改）。
更改默认货架位置
默认情况下，shelf 目录位于您的项目目录下。但是，您可能想要更改默认的货架位置。这可能很有用，例如，如果您想在清理工作副本时避免意外删除书架，或者如果您想将它们存储在单独的存储库中，以便在团队成员之间共享书架。
按Ctrl+Alt+S打开 IDE 设置并选择版本控制 | 架子。
单击更改货架位置并在打开的对话框中指定新位置。
如有必要，选择将架子移到新位置以将现有架子移动到新目录。
观看此视频教程，了解如何从书架中受益，以便能够在不丢失未完成工作的情况下切换到不同的任务：
存储更改
有时可能需要恢复工作副本以匹配 HEAD 提交，但您不想丢失已经完成的工作。如果您了解到上游更改可能与您正在做的事情相关，或者您需要进行一些紧急修复，则可能会发生这种情况。
存储涉及记录 HEAD 提交和工作目录 (stash) 的当前状态之间的差异。也可以隐藏对索引的更改。
取消存储涉及将存储的存储应用到分支。
您可以将存储应用到现有分支或在其基础上创建新分支。
存储可以根据需要多次应用于所需的任何分支，只需切换到所需的分支。请记住：
在一系列提交之后应用存储会导致需要解决的冲突。
您不能将存储应用到“脏”工作副本，即具有未提交更改的工作副本。
保存对存储的更改
从主菜单中，选择 。
在打开的Stash对话框中，选择适当的 Git 根并确保签出正确的分支。
在消息字段中描述您将要存储的更改。
要存储本地更改并将索引中暂存的更改带到您的工作树以进行检查和测试，请选择保留索引选项。
单击创建存储。
应用存储
从主菜单中，选择 。
选择要应用存储的 Git 根目录，并确保签出正确的分支。
从列表中选择要应用的存储。
如果要检查所选存储中哪些文件受到影响，请单击查看。
要在应用后删除选定的存储，请选择Pop stash选项。
要同时应用隐藏索引修改，请选择恢复索引选项。
如果要基于选定的存储创建一个新分支，而不是将其应用于当前签出的分支，请在作为新分支字段中键入该分支的名称。
要删除存储，请在列表中选择它并单击Drop。要删除所有存储，请单击清除。
将更改分组到不同的更改列表中
当您处理多个相关功能时，您可能会发现将更改分组到不同的更改列表中很方便。与使用功能分支来处理多个任务相比，这种方法有其优点和缺点。
优点：
您可以轻松地在不同的逻辑更改集之间切换，并将它们彼此分开提交。
与出于相同目的使用分支不同，您可以随时进行所有更改，而无需在分支之间切换，如果您的项目非常大，这可能需要一段时间。
测试不同功能如何协同工作很方便。
您可以在构建服务器上远程运行更改列表。
缺点：
虽然与分支相比，使用更改列表似乎是一个更轻量级的选项，但它并不安全，因为在您提交并推送它们之前没有备份您的更改。如果您的本地工作副本发生问题，您的所有更改都将丢失，因为它们不属于 Git 项目历史记录。
不可能对特性进行原子测试。
不可能就同一功能进行协作。此外，除非您通过电子邮件发送带有更改的补丁，否则您无法从不同的机器上做出贡献，这可能不是很方便。
所有更改列表都显示在 本地更改视图中所有修改的文件都自动放置在活动更改列表中，这是更改更改列表，除非您创建了一个不同的更改列表并使其处于活动状态。
更改列表显示在 本地更改视图中 最初，有一个默认更改列表。它被称为Changes，所有新的更改都会自动放置在此更改列表中。还有一个Unversioned Files 更改列表，它对尚未添加到 VCS 的新创建的文件进行分组。
您可以根据需要创建任意数量的更改列表，并随时激活其中的任何一个。您可以将任何未提交的更改移动到任何更改列表。
创建一个新的变更列表
在Local Changes视图中，单击
工具栏上的 并选择New Changelist。在“新建更改列表”对话框中，指定新更改列表的名称，并添加描述（可选）。
设置活动更改列表
在Local Changes视图中，选择一个非活动的更改列表并按下Ctrl+Space或右键单击它，然后从上下文菜单中选择Set Active Changelist 。所有新更改将自动放置在此更改列表中。
在更改列表之间移动更改
在本地更改视图中，选择要移动到另一个更改列表的更改。
右键单击所选内容或单击
工具栏并选择Move to Another Changelist Alt+Shift+M。在打开的对话框中，选择现有更改列表或输入新更改列表的名称。
您可以选择使目标更改列表处于活动状态并为其跟踪上下文（WebStorm 将保存与此更改列表关联的上下文，并在此更改列表激活时将其恢复）。
删除更改列表
右键单击更改列表并从上下文菜单中选择删除更改列表。
使用功能分支
Git 中的一个分支代表一个独立的开发线，因此，如果您正在开发一个单独的功能，并且在您准备好分享您的工作结果并将它们集成到 之前，您想要完成和测试master，那么在功能分支中执行它是最好的解决方案。这样您可以确保不稳定的代码不会提交到项目的主代码库，并且您可以在必要时轻松切换到其他任务。
优点：
与使用更改列表对更改进行分组相反，使用功能分支是安全的。在您向 Git 提交更改后，它们将成为 Git 项目历史记录的一部分，因此即使您损坏了工作树，您也始终可以通过Git reflog恢复您的提交。推送更改后，它们会被备份。
您可以开发并行的非相关功能并以原子方式对其进行测试。
当您在分支中完成开发后，您可以重新排序或压缩提交，以便您的历史是线性且干净的。
很容易就您的功能进行协作，或者从不同的机器上开发它。
缺点：
在非常大的项目上切换分支可能需要一些时间。
一起测试相关功能不是很方便。
您必须学习使用功能分支并将更改集成到主代码库的工作流程。
有两种主要方法可以使用功能分支并将您的更改集成到主代码库中：
使用合并来集成来自功能分支的更改
合并选项的主要好处是完全可追溯性，因为合并到主代码库中的提交保留了它们的原始哈希和作者，并且作为一个功能一部分的所有提交可以组合在一起。
此工作流程适用于提交对主代码库的更改涉及拉取请求或分层批准程序的项目，因为现有分支不会以任何方式更改。
这种方法的主要缺点是每次需要合并更改时都会创建无关的合并提交，这会严重污染项目历史并使其难以阅读。
使用 rebase 集成来自功能分支的更改
此选项的主要好处是您可以获得清晰的项目历史记录，其他人易于阅读和理解。您的日志不包含merge操作产生的不必要的合并提交，并且您会获得易于导航和搜索的线性历史记录。
但是，在决定采用此工作流程时，您应该记住，rebase它会重写项目历史记录，因为它会为原始功能分支中的每个提交创建新的提交，因此它们将具有不同的哈希值，这会阻碍可追溯性。
在开发过程中经常提交更改。
将您的分支推送到远程存储库。这应该用于备份，以便您可以在不同的机器上协作或工作。
不时将您的功能分支重新设置为基础
master。仅当您的功能分支很长时，这样做才有意义。这有助于：确保您的功能分支
master不要分开太远。当您最终将更改集成到主代码库中时，避免解决大量冲突。当您定期变基时，您可以迭代地解决冲突，并且最终不会因长期差异而苦苦挣扎。
加快检查分支，因为一旦分支足够分散，分支之间的切换就会变慢。
变基涉及以下步骤：
master当您需要执行与您的功能无关的工作时切换到。当您返回到您的功能分支时，执行Checkout 和 Rebase 到 Current。审查和测试您的功能，并进行必要的修复。
完成功能后执行交互式变基。这允许您重新排序和压缩提交，以使您的功能分支历史看起来漂亮而干净。
当您准备好将工作结果集成到主分支中时（例如
master），请执行以下操作：