Git 工作流程 - 更改分支和缓慢的重新编译
我从事一个大型 Scala 项目，我们使用 Git 进行版本控制。我的工作流程是在我自己的分支中开发新功能，并在需要时进行切换。代码的各个版本都在各自的分支中。一切都非常标准。
如果我必须修复某个版本的代码中的错误，我将切换到正确的分支，修复错误，提交，然后切换回原来的位置。
问题是，虽然 git 可以立即切换到另一个分支，但我必须重新编译代码。这需要几分钟。然后修复错误，切换回我自己的分支并再次重新编译，这又需要几分钟。这似乎违背了 Git 如此之快的目的。
还有其他人遇到过这种情况吗？有没有办法解决它。我确信这不是 Scala 特有的问题（尽管 Scala 的编译速度非常慢）。
3年多后更新
过去几年我一直在使用 @djs 答案 (git-new-workdir)。这对我来说非常有效。我有一个主目录和其他几个目录（如生产、下一个版本等），当我需要在那里工作时，我会切换到这些目录。开销非常小，这意味着您可以快速切换到生产，测试某些内容，然后切换回您正在处理的内容。
7年多后更新
它看起来像git -worktree 是 git-new-workdir 的替代品。使用方法：
cd ~/git/my-repo
git worktree add ~/git/my-linked-repo
I work on a large Scala project where we use Git for version control. My workflow is to work on new features in my own branch and switch when needed. Various releases of the code are in their own branches. All very standard.
If I have to fix a bug in a certain version of the code, I'll switch to the correct branch, fix the bug, commit then switch back to where I was.
The problem is that although git is instant at switching to another branch once I'm there I have to recompile the code. Which takes several minutes. Then fix the bug, switch back to my own branch and do another recompile, which takes another few minutes. It seems to defeat the purpose of Git being so fast.
Has anyone else encountered this? Are there ways around it. I'm sure it's not a Scala specific problem (although Scala is epically slow at compiling).
update 3+ years later
I've been using @djs answer (git-new-workdir) for the last few years. It's worked very well for me. I have a master directory and several other directories (like production, next-release etc) that I switch to when I need to do work there. There's very little overhead and it means you can quickly switch to say, production, to test something, then switch back to what you were working on.
update 7+ years later
It looks like git-worktree is the replacement for git-new-workdir. To use:
cd ~/git/my-repo
git worktree add ~/git/my-linked-repo
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
假设您不想更改构建过程（基于哈希而不是时间戳），您可能需要查看 git-new-workdir git 源代码 contrib 目录中的脚本。与克隆建议一样，您将获得多个工作副本，但您将获得一个具有多个工作副本的存储库，而不是两个独立的存储库。因此，本地存储库之间无需推拉。
它是一个 shell 脚本，只能在类 UNIX 系统上运行，但这个概念可以在现代版本的 Windows 上复制。
Assuming you don't want to change your build process (hash-based instead of timestamped), you might want to look at the git-new-workdir script in the contrib directory of git source. Like the clone suggestion, you'll get multiple working copies, but instead of two independent repositories, you'll get one with multiple working copies. So, no pushing and pulling between local repositories.
It's a shell script and only runs on unix-like systems, but the concept can be replicated on modern versions of Windows.
假设您的构建系统对依赖关系不是过于热心（也许它认为需要重建，但实际上并非如此），解决此问题的主要方法是克隆您的存储库：
然后您可以在额外的克隆中工作，并且从它推回到你的主要部分。 （您应该只推送到未签出的分支，但这就是这里的重点。如果您愿意，您也可以拉动甚至获取并重置或分支 -f 。）
这不会真正占用很多时间空间，或者； Git 硬链接存储库中的对象以进行本地克隆，因此额外的空间将只是额外的签出副本。
Assuming that your build system isn't overzealous about dependencies (maybe it thinks it needs to rebuild when it doesn't actually), the primary way to work around this is to clone your repository:
You can then work in your extra clone, and push from it back into your main one. (You should only push to branches which aren't checked out, but that's the whole point here. You could also pull or even fetch and reset or branch -f if you wanted.)
And this won't really take up a lot of space, either; Git hardlinks the objects within the repository for local clones, so the extra space will just be the extra checked-out copy.
您可以尝试通过覆盖outputDirectoryName为不同的分支使用不同的目标目录。也许选择 git 分支名称并将输出目录设置为 target-
You could try using different target directories for different branches by overriding the outputDirectoryName. Maybe picking up the git branch name and setting the output directory to target-
<branch>; although that would mean every new branch starts from scratch.您可以使用 [sbt][1] 或“快速 scala 编译器”来大幅缩短 scala 编译时间。两者都允许将编译器保留在内存中，从而极大地缩短编译时间。
每个分支使用一个目录可以避免多次重新编译。但该工作流程得到了 Mercurial 的更好支持。
You can improve scala compile times drastically with by using [sbt][1] or the "fast scala compiler". Both allow to keep the compiler in memory, which improves compile times enormously.
Using one directory per branch allows to avoid so many recompiles. But that workflow is better supported by mercurial.