我在现有目录中启动新的git repo时遇到问题。我们当前正在接收带有文件系统的tar文件,我们将其解包,创建一个git repo,然后再运行测试。文件系统需要成为git repo的原因是因为我们的测试流程依赖于此。
我们现在正在做的是:
tar xf <file.tgz>
git init
git add .
git commit
我们遇到的问题是“git add”。大约需要10分钟。有没有办法更快地做到这一点?就像“git init”的选项一样,它会在启动repo时添加目录中的所有文件?似乎没有把它放在git手册中,但我想我会问这个问题以防万一有人对它有任何意见。
替代方法是,如果有一种方法可以获取尚未提交的本地仓库中的更改。这些文件从一开始就存在于git repo中,但由于我不确定我们不希望在它通过交付检查之前提交此repo中的更改。
祝你好运, 约翰
答案 0 :(得分:0)
没有更快的方法可以做到这一点。 git add
将为您添加的每个文件创建Git对象,因此如果您的工作目录很大,可能需要一段时间才能完成。
通常情况下,虽然自上次运行以来每个文件都没有发生变化,但机率很高,因此将存储库保留在原位,只需更换每个文件就可以节省一些时间,因为Git赢了不为它已经知道的文件创建新对象。
但是,如果你已经有了一个存储库,那么所有这些都没有意义。您应该设置正确的持续集成设置以重用现有的存储库结构。提交在本地发生,到您的本地存储库。所以,仅仅因为你提交了一些东西,这并不意味着它与他人共享。因此,如果您使用单独的存储库设置测试服务器,则可以推送到测试存储库,触发测试,然后在最终将其推送到其他人都可以访问的中央存储库之前解决所有问题。
答案 1 :(得分:0)
为什么不提交更改? Git是一个分布式系统,因此您可以在一次性分支或“稳定”的情况下提交更改。分支,然后标记提交并将分支倒回到提交之前的位置 - 从而使分支不受干扰并且提交标记。您甚至可以选择分离的HEAD
并在那里记录新的提交,然后将其推送到要运行测试的仓库。
我建议您研究这些可能性,并说服您的管理层这是要走的路:没有必要触及维护交付产品的分支进行测试。
如果具有这些存储库的计算机不易连接,以及为什么需要使用tarball,请考虑使用git bundle
,它已经精确地实现了通过sneakernet传输Git提交的方法。
有了它,您的工作流程将是这样的:
在主回购中(比如说,我们是&#34; master&#34;分支):
git checkout -b testing
...
git commit ...
...
git bundle create /tmp/testing.bundle master..testing
将/tmp/testing.bundle
转移到目标计算机。
在目标回购中:
git pull /tmp/testing.bundle testing
或者更合适的东西,比如说
git fetch /tmp/testing.bundle +testing:testing
git checkout testing
无论如何,如果您不得不忍受这种情况,请执行@poke建议的操作:在测试位置维护存储库,当您收到另一个tarball时,将其展开在该存储库的工作树上然后运行
git add --all
引用--add
上的手册:
-A
--all
与
-u
类似,但除了索引外还与工作树中的文件匹配。这意味着它将找到新文件以及暂存已修改内容并删除不再位于工作树中的文件。
因此,基本上它只会添加到已修改的索引文件中。
一个潜在的问题是删除: tarball中丢失的文件与工作树相比,不知何故会自动删除。