Dav*_*ave 22 git branch scala recompile git-worktree
我在一个大型Scala项目上工作,我们使用Git进行版本控制.我的工作流程是在我自己的分支中处理新功能并在需要时切换.各种版本的代码都在自己的分支中.一切都很标准.
如果我必须修复某个版本的代码中的错误,我将切换到正确的分支,修复错误,提交然后切换回我所在的位置.
问题是虽然git在我转到另一个分支后立即进行,我必须重新编译代码.这需要几分钟.然后修复bug,切换回我自己的分支并再做一次重新编译,这需要几分钟.这似乎打败了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
假设你的构建系统对依赖关系并不过分(可能它认为它实际上不需要重建),解决这个问题的主要方法是克隆你的存储库:
git clone my-repo my-repo2
然后,您可以在额外的克隆中工作,然后将其推回到主克隆中.(你应该只推送到未检出的分支,但这就是这里的全部要点.如果你愿意的话,你也可以拉动甚至取回和重置或分支-f.)
这也不会占用太多空间; Git将存储库中的对象硬链接到本地克隆,因此额外的空间将只是额外的签出副本.
假设您不想更改构建过程（基于哈希而不是加时间戳），则可能要查看git source的contrib目录中的git-new-workdir脚本。像克隆建议一样，您将获得多个工作副本，但是将获得一个具有多个工作副本的副本，而不是两个独立的存储库。因此，在本地存储库之间不会进行任何推拉操作。
它是一个Shell脚本，仅在类似Unix的系统上运行，但是该概念可以在Windows的现代版本中复制。
| 归档时间： |
|
| 查看次数： |
1911 次 |
| 最近记录： |