Kei*_*yer 5 git version-control
我的公司正在评估迁移到新的 SCM 系统，而 git 是正在考虑的最终竞争者之一。在开始之前，我们列出了需要支持的用例列表。
我对 git 没有可靠答案的一个用例是在单个“项目”中同时处理多个“变更集”。
在我们当前的 SCM 中，当您“签出”文件时，您将文件与“任务”相关联。只要您的更改位于不同的文件中，您就可以根据需要激活任意多个“任务”。
根据我使用 git 的经验，在将更改暂存以进行提交之前，您不会将更改关联到“更改集”（提交）。但是，只有一个暂存区域，因此您一次只能对一个“变更集”执行此操作（并且还无法关联摘要/描述）。
还有“存储”，但其典型用途是将多个逻辑更改合并到一个构建中以运行测试，因此它们需要同时“活动”。
当我写这篇文章时，我想到了一个可能的工作流程：在启动时对每个“变更集”进行一次提交，并在进行进一步更改时提交 + 'rebase -i'/将其压缩到适当的提交中。然而，这似乎过于复杂，并且可能不会受到好评。
有没有更好的办法？或者有一个令人信服的理由来说明为什么我们应该停止使用此工作流程（需要非常令人信服）？
提前致谢！
小智 0
一年多前，我们作为一个大型开发团队转向了 git，它为我们提供了很好的服务。
你是对的，当使用 git 时，你一次只有一个可用的工作空间。
与其他 SCM 一样，git 并不真正跟踪单个文件。即使您进行重命名，它实际上也会存储为删除并添加到新名称下。因此，您添加带有任务的文件的工作流程需要更改。
相反，您可以将任务添加为分支。git 中的分支非常轻量级并且工作得很好。一个示例工作流程是，您将发布代码放在 master 分支（主干）中，当新任务出现时，您将创建一个 master 分支，在那里进行更改、验证、测试、批准并合并到 master 中。您可以保留分支作为参考或清理它。
如果您可能需要支持和修补产品的多个版本，那么采用发布分支系统可能更适合您。master 为您的下一个版本保留，并且随着版本的发布，创建一个 release/<version> 分支。这使您可以稍后返回并修补版本并重新构建，确信您使用的是与您发布的相同的代码库。还提供了一个对发布之间完成的工作进行度量的好地方。
Stash，实际上用于在分支之间切换时临时保存更改。例如，如果您开始执行一项任务，并在多次编辑后意识到您处于错误的分支中。Stash 会将这些更改移至保存空间，允许您签出正确的分支并将更改弹出回工作区。
如果您有多个开发人员同时工作，您可能希望避免使用变基方法并使用合并方法。由于 git 存储库是一个包含父提交哈希的提交链，因此变基会导致提交被重写，因此需要开发人员从托管存储库的服务器重新克隆。合并方法只需要您在推送您的更改之前合并已推送到服务器的其他人的更改。
希望有帮助。