git - 使用 Git 的多个同时变更集

Question

我的公司正在评估迁移到新的 SCM 系统，而 git 是被考虑的最终竞争者之一。在开始之前，我们列出了需要支持的用例。

我对 git 没有可靠答案的一个用例是在单个“项目”中同时处理多个“变更集”。

在我们当前的 SCM 中，当您“ checkout ”时，您将文件与“任务”相关联。只要您的更改在不同的文件中，您就可以根据需要激活任意数量的“任务”。

根据我使用 git 的经验，您不会将更改关联到“变更集”(提交)中，直到您将它们暂存以进行提交。但是，只有一个暂存区，因此您一次只能对一个“变更集”执行此操作(并且还不能关联摘要/描述)。

还有“存储”，但它的典型用途是将多个逻辑更改 merge 到一个构建中以运行测试，因此它们需要同时“活跃”。

在我写这篇文章时，我想到了一个可能的工作流程:在启动时对每个“变更集”进行一次提交，然后在进行进一步更改时提交 + 'rebase -i'/将其压缩到适当的提交中。然而，这似乎过于复杂并且可能不会受到欢迎。

有没有更好的方法？或者我们应该停止使用此工作流的令人信服的理由(需要非常有说服力)？

提前致谢!

Answer 1

作为一个大型开发团队，我们在一年多前转向了 git，它为我们提供了很好的服务。

你是对的，当使用 git 时你一次只有一个可用的工作空间。

git 并不像其他 SCM 那样真正跟踪单个文件。即使您进行了重命名，它实际上也存储为新名称下的删除和添加。因此，您需要更改添加带有任务的文件的工作流程。

相反，您可以将您的任务添加为一个分支。 git 中的分支非常轻量并且工作得很好。一个示例工作流是您在 master 分支(主干)中有您的发布代码，并且随着新任务的出现，您将创建一个 master 分支，在那里进行更改，验证、测试、批准并 merge 到 master 中。您可以保留分支作为引用或清理它。

在您可能需要支持和修补产品的多个版本的情况下，采用发布分支系统可能更适合您。 master 为您的下一个版本保留，并且随着版本的发布，创建一个 release/ 分支。这使您可以稍后返回并修复一个版本并重新构建，确信您使用的是与交付时相同的代码库。还提供了一个很好的地方来衡量发布之间完成的工作。

Stash，真正用于在分支之间切换时临时保存更改。例如，如果您开始执行一项任务并在多次编辑后意识到您在错误的分支中。 Stash 会将这些更改移至保留空间，让您可以 check out 正确的分支并将更改 pop 回您的工作区。

如果您有多个开发人员同时工作，您可能希望避开 rebase 方法并使用 merge 方法。因为 git 存储库是包含父提交哈希的提交链， rebase 会导致提交被重写，因此需要开发人员从托管您的存储库的服务器重新克隆。 merge 方法只需要您在推送您的更改之前 merge 已推送到服务器的其他更改。

希望对您有所帮助。