git clone --shared和--reference有什么区别？ [英] What are the differences between git clone --shared and --reference?

问题描述

阅读完文档后，我仍然不太明白 - 共享和 - 引用之间的
差异<回购> 。它们看起来很相似。

1. 之间有什么区别？ -shared 和
   - 参考<回购> 选项？
   

2. 当
   的多个本地克隆是另一个本地克隆时，它们可用于节省驱动器空间吗？

   >



3. 每个本地克隆都可以检出不同的分支吗？





注意：通过使用 git clone - 我知道我可以使用多个带有截断的
历史记录的浅层克隆。深度<深度> ，但每个克隆仍然需要
重复 至少一些 历史记录才能做到这一点，所以我是
，认为这可能不是节省驱动器空间的最佳方式（尽管它
总比没有好）。





背景





有时候，我喜欢有不止一次的工作副本结账在
存储库中，所以我创建了多个克隆，每个克隆都有自己的结帐。





然而，我并不需要每个克隆克隆，只是我的分支机构的最新
最新版本，所以我可以通过让每个克隆使用标签，提交，树和blob对象来节省大量的驱动器
空间
原始本地克隆（例如，通过符号链接）。
$ b

git clone documentation h2>



我检查了 git clone 文档查看是否有任何I
可以使用。



- 共享





我看到有一个 - 共享选项：
$ b




当要克隆的存储库位于本地计算机上时，而不是使用硬
链接，自动设置 .git / objects / info / alternates 来共享对象
与源存储库。生成的存储库从它自己的任何
对象开始。




这看起来像 可能 适用于帮助我节省驱动器空间
与具有不同签出的多个克隆，因为每个克隆与原始本地克隆共享
对象。





- reference< repository>





然后我还看到 - reference< repository> 选项：

lockquote


如果参考存储库位于本地机器，自动设置
.git / objects / info / alternates 以从参考
存储库中获取对象。使用已经存在的存储库作为备用，将需要从克隆的存储库中复制少于
的对象，从而减少网络
和本地存储成本。





注意：请参阅 - 共享选项的注。




这说明它可以降低本地存储成本，所以这可能对
很有用。

解决方案

这两个选项都会更新 .git / objects / info / alternates 以指向源存储库，这可能很危险，因此文档中的两个选项都存在警告注释。



- 共享选项不会将对象复制到克隆中。这是主要的区别。


$ b

- reference 使用额外的储存库参数。在克隆过程中，使用 - reference 仍然会将对象复制到目标中，但是您可以指定在现有源中已经存在的对象时从对象库中获取对象的对象。这可以通过使用 - reference


$将路径传递到更快/本地设备上的存储库来减少源存储库中的网络时间和IO b $ b

亲自看看





创建 - 共享克隆和一个 - 引用克隆。使用 git count-objects -v 来计数每个对象。您会注意到共享克隆没有对象，并且参考克隆具有与源相同数量的对象。此外，请注意文件系统中每个文件的大小差异。如果您要移动源代码并在共享和参考存储库中测试 git log ，则共享克隆中的日志不可用，但在参考克隆中工作正常。 / p>


After reading the documentation, I still don't really understand what the differences are between --shared and --reference <repo>. They seem so similar.

1. What are the differences between the --shared and --reference <repo> options?

2. Can they be used to save drive space when making multiple local clones of another local clone?

3. Can each local clone have a different branch checked-out?

Note: I'm aware that I can use multiple shallow clones with truncated history by using git clone --depth <depth>, but each clone still has to duplicate at least some history in order to do that, so I was thinking that maybe it's not the most optimal way to save drive space (though it is better than nothing).

Background

Sometimes I like to have more than one checkout of my working copy in a repository, so I create multiple clones, where each clone has its own checkout.

However, I don't really need the whole history with each clone, just the most up-to-date versions of my branches, so I could possibly save a lot of drive space by having each clone use the tag, commit, tree, and blob objects from the original local clone (for example, via symlinks for something).

git clone documentation

I checked the git clone documentation to see if there's anything I can use.

--shared

I saw that there's a --shared option:

When the repository to clone is on the local machine, instead of using hard links, automatically setup .git/objects/info/alternates to share the objects with the source repository. The resulting repository starts out without any object of its own.

This looks like it might be useful for helping me to save drive space with multiple clones that have different checkouts, since each clone shares objects with the original local clone.

--reference <repository>

Then I also saw the --reference <repository> option:

If the reference repository is on the local machine, automatically setup .git/objects/info/alternates to obtain objects from the reference repository. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs.

NOTE: see the NOTE for the --shared option.

This says that it will reduce local storage costs, so this might be useful as well.

解决方案

Both options update .git/objects/info/alternates to point to the source repository, which could be dangerous hence the warning note is present on both options in documentation.

The --shared option does not copy the objects into the clone. This is the main difference.

The --reference uses an additional repository parameter. Using --reference still copies the objects into destination during the clone, however you are specifying objects be copied from an existing source when they are already available in the reference repository. This can reduce network time and IO from the source repository by passing the path to a repository on a faster/local device using --reference

See for yourself

Create a --shared clone and a --reference clone. Count the objects in each using git count-objects -v. You'll notice the shared clone has no objects, and the reference clone has the same number of objects as the source. Further, notice the size difference of each in your file system. If you were to move the source, and test git log in both shared and reference repositories, the log is unavailable in the shared clone, but works fine in the reference clone.

这篇关于git clone --shared和--reference有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！