我的公司正在评估迁移到新的 SCM 系统，而 git 是正在考虑的最终竞争者之一。在开始之前，我们提出了需要支持的用例列表。
我对 git 没有明确答案的一个用例是在单个“项目”中同时处理多个“变更集”。
在我们当前的 SCM 中，您在“签出”时将文件与“任务”相关联。只要您的更改位于不同的文件中，您就可以根据需要激活任意数量的“任务”。
根据我使用 git 的经验，您不会将更改关联到“变更集”（提交），直到您将它们暂存以进行提交。但是，只有一个暂存区域，因此您一次只能为一个“变更集”执行此操作（并且还不能关联摘要/描述）。
还有“stash”，但它的典型用途是将多个逻辑更改合并到一个构建中以运行测试，因此它们需要同时“活跃”。
在我写这篇文章时，我想到了一个可能的工作流程：在您启动它时为每个“变更集”进行一次提交，并在您进行进一步更改时将其提交 + 'rebase -i'/squash 到适当的提交中。然而，这似乎过于复杂，可能不会受到欢迎。
有没有更好的办法？或者我们为什么应该停止使用这个工作流程的令人信服的理由（需要非常有说服力）？
提前致谢！
一年多前，我们作为一个大型开发团队切换到 git，它为我们提供了很好的服务。
你是对的，当使用 git 时，你一次只有一个可用的工作空间。
git 并不像其他 SCM 那样真正跟踪单个文件。即使您进行重命名，它也确实存储为删除并以新名称添加。因此，您需要更改添加带有任务的文件的工作流程。
相反，您会将任务添加为分支。git 中的分支非常轻量级并且运行良好。一个示例工作流程是，您将发布代码放在主分支（主干）中，并且随着新任务的出现，您将创建一个主分支，在那里进行更改，验证，测试，批准并合并到主分支。您可以保留分支作为参考或清理它。
如果您可能需要支持和修补产品的多个版本，那么采用发布分支系统可能更适合您。master 是为你的下一个版本保留的，随着版本的发布，创建一个 release/<version> 分支。这使您可以稍后返回并修复一个版本并重新构建，确信您使用的是与您发布的相同的代码库。还提供了一个很好的地方来衡量发布之间完成的工作。
Stash，实际上用于在您在分支之间切换时临时保留更改。例如，如果您开始执行一项任务并在多次编辑后意识到您在错误的分支中。Stash 会将这些更改移动到保存空间中，允许您签出正确的分支并将更改弹出回您的工作区。
如果您有多个开发人员同时工作，您可能希望避开变基方法并使用合并方法。由于 git 存储库是包含父提交哈希的提交链，因此变基会导致重新编写提交，因此需要开发人员从托管存储库的服务器重新克隆。合并方法只要求您在推送您的更改之前合并其他已推送到服务器的更改。
希望有帮助。
这听起来像是一个 UI 级别的功能，而不是需要成为 SCM 核心的东西。我知道（例如）Eclipse 在您想使用的任何 SCM 之上将这样的功能分层。
在 SCM 本身中没有它的困难在于记住哪些文件伴随着哪些更改。我同意 JasonM 的观点，这里正确的做法是在本地使用分支，而不是相互混合更改——考虑一下为什么要混合更改，以及当你正在处理的两个更改需要时你会做什么触摸同一个文件。我工作过的各个地方都有与您描述的类似的工作流程，主要是为了让人们不会一次与一件事联系在一起，主要是通过记住哪些文件应该去哪里（而不是使用工具）。他们所有人都会受益于能够使用多个本地分支而不是将更改混合在一起，尽管我敢肯定不是每个人都会这样看，尤其是在开始时。