我正在寻找您从一个软件开发任务切换到另一个软件开发任务所执行的一系列步骤的工作流类型描述。如果某个步骤涉及工具，请说明使用哪个工具以及如何使用。工作流的目标是尽可能顺利地从任务 #1 过渡到任务 #2，然后再返回任务 #1。
考虑这种情况......
您可以在新版本的源代码中修复错误，但它必须是稳定版本，并且不能包含您当前正在处理的不完整功能。
Alt + Tab 是我们的做法。
任务切换是大脑的事情。我认为没有工具可以为您做到这一点。如果有，我也很感兴趣。
每个人都有自己的准备方式，有些人根本不准备，而在另一件事上，比如快速，有些人需要更多时间等。这取决于男人/女人。
当然，您可以尝试创建一些心理里程碑（记笔记，放置提醒等）以在回到任务时返回到它，但这又取决于其他因素（任务切换了多长时间，办公室的安静程度） ，熟悉任务，月相等）。
我认为开发人员在任务之间切换的最有效方式是主观的。同时，您是否阅读过Joel Spolsky的被认为有害的人工任务开关？
我想说您在描述的场景中需要采取的步骤 100% 取决于您设置的开发环境和工具。
使用 Perforce 进行源代码版本控制，我们建立了一个分支系统，其中发布与开发工作是分开的，所有开发分支都源自一个“接受”分支。每个分支用于单个问题，或用于一组非常密切相关的问题。在将更改集成到验收分支之前，不能在分支中处理其他问题。
是的，这确实意味着我们有很多分支机构。是的，我们做了很多同步（接受到工作分支）和集成（工作分支到接受）。但是，当涉及到轻松地从一项任务切换到另一项任务、回到测试构建、发现两个相互咬的问题等时，它的价值是不可估量的。
在开发完成后（包括他们自己的测试），QA 团队会测试一个问题。首先在自己的分支中隔离。之后将其集成到验收分支中，并进行回归测试以发现任何相互影响的独立问题的问题。当发布的所有问题都因此被集成到验收中时，QA 团队将执行完整的回归和新功能测试。
因此，验收分支始终是应用程序开发的“最新”状态。
在此设置中，您描述的场景将如下所示：
保留我当前的任务，可能检查任何未完成的更改，以免在我的计算机崩溃时丢失它们。如果这意味着破坏该分支的每日构建，我不会签入，除非很容易修复编译错误。（请注意，我们的应用程序套件中有许多应用程序，虽然我的更改可能会在我正在开发的应用程序中编译，但它们仍可能会破坏我们套件中其他应用程序的编译）我们的规则是：每次提交都可能破坏功能，但是不得破坏构建过程。
找到一个“空”分支——当前没有用于任何开发工作的分支，或者，如果所有分支都被占用，则创建一个新分支。
强制同步接受分支和选定的工作分支，这样我的机器就可以保证两个分支的最新状态。
将验收分支的最新状态同步（必要时强制）到工作分支，所以选中的工作分支与验收分支相同。
在 IDE 中打开该分支的应用程序套件，调试并解决。提交到工作分支。
告诉 QA 在工作分支中查看它。如果他们对此感到满意，请将更改整合到接受，以便他们可以继续测试。
将 IDE 切换回我之前工作的分支中的应用程序套件上工作。
冲洗并重复。
考虑到您的情况，
您可以在另一个工作副本中检查源的稳定版本，更正错误，提交。
当您回到未完成的工作时，请进行更新并继续工作。
当你在做某事时，你通常会有一些想法，很少有你打算做的事情，一些不清楚的事情，必须在以后解决。当您切换到其他任务时，它往往会丢失。
我发现把它们写下来很有用——拍一张大脑快照。以后更容易恢复它并更快地回到原来的任务。
我在 Task/Todo 项目中记录了我正在处理的每个文件，并在大约 我离开它的时间。然后我保存并关闭每个文件，以防止它们分散我的注意力/消除混乱/为我的桌面上的新任务创建空间。我有跳蚤的记忆，所以我需要我能得到的所有帮助。