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