Git克隆已经是克隆的存储库 [英] Git cloning a repository that is already a clone

问题描述

我不确定这是否是一个愚蠢的问题，但是对于已经克隆另一个远程存储库的存储库的 git clone 是否存在任何不良的副作用库？

解决方案

没有任何副作用，但您应该准确理解克隆存储库时发生的情况。

某些理论

问题是当您以正常方式克隆存储库时 - 也就是说，没有调整任何时髦的旋钮当调用 git clone —你不用 em> 它确实包含完全相同的历史，但它有不同的分支布局。

以非科学的方式解释它，让我们举个例子：

1. 源代码回购包含分支master，dev和release。
   
   

   它还包含两个标签，v1和v2。
   
   

   该存储库中的HEAD引用指向分支master。




2. 当你克隆这个仓库时，你的本地克隆会有： >三个远程追踪分支：origin / master，origin / dev
   和origin / release。
   

3. 两个标签，v1和v2。

名为master的 local 指向相同的提交
远程跟踪分支origin / master执行的操作。 >如果你现在克隆这个克隆，结果会有：





• 一个远程追踪分支origin / master。




• A
  

• 两个标签，v1和v2。

这可能显得很奇怪，但实际上这在手册页的
中明确说明：

将存储库克隆到新创建的目录中，为克隆存储库中的每个分支创建远程跟踪
分支（使用 git branch -r ），
，并创建并检出从克隆的
存储库当前活动分支中分出的初始分支。

在克隆之后，不带参数的纯粹git fetch将更新所有
远程跟踪分支，并且不带参数的git pull将另外
将远程主分支合并到当前主分支，如果有任何
（当--single-branch给出时这是不真实的;
$ b 这个默认配置是通过在 refs / remotes / origin 下创建对远程
分支头的引用来实现的。 code>并初始化
remote.origin.url 和 remote.origin.fetch 配置变量。


因此，在 git clone 中的clone意味着所有的历史记录被克隆（除非另有说明），但分支的布局是不同的。





推理是这样的：正是因为 Git是一个分布式VCS，
您的非裸仓库中的所有分行都是您的，因为您认为
对您有效，只有您决定如何与
同步其他仓库中的分行，何时和为什么。

所以当你克隆一个回购正常的方式Git：

• 仅将分支 local 提取到该回购：没有远程跟踪分支
  被收购。

  
  
  

  这是因为远程跟踪分支可作为其他存储库
  的书签，并且不会对其执行任何工作。

  
  
  

  为了理解Git的行为，请考虑当你想要Joe的工作时，大部分时间克隆
  a的存储库，而不是从他与之交流的随机存储库中获取的东西
  。

>


• 创建一个本地分支并将其检出。

  创建一个本地分支并将其检出。

  >
  
  

  这只是一种方便，只会增加可能的混淆。

< h3>做什么

好的， git clone 接受一个--mirror命令行选项，
会生成原始回购的真实副本，但生成的回购将会是
。
如果您使用--mirror
命令行选项再次克隆生成的repo，您​​将再次获得真实副本。

<如果你做了一个正常的克隆（我认为你做的），你仍然可以使用
从该存储库中获取所有的东西，但是 git clone won不要削减它：
你需要做 git init 然后加上 git remote add origin< url>
之后是特制的 git fetch 。

具体如何制作 git fetch 取决于你真正想要
从源代码仓库中获取什么，以及在哪里放置它。
首先，请考虑源代码回购现在拥有origin / master和master，并且它们可能包含不同的历史记录。

另外请注意，使用 git clone --mirror 来克隆非裸回购将可行，但结果不会很明智，因为在这种情况下 git clone 将完全复制所有分支机构 - 本地和远程跟踪 - 从源代码库回收逐字记录，和远程跟踪分支，而不是您通常希望在裸机中出现的内容回购。

I am not sure whether this is a dumb question, but are there any ill side-effects to do a git clone of a repository that is already clone of another remote repository?

解决方案

There's no side effects but you should understand exactly what happens when you clone a repository.

Some theory

The "problem" is that when you clone a repository "the normal way"—that is, without any funky knobs adjusted when calling git clone—you do not end up with a repository which is the same as the source one. It indeed contains exactly the same history but it has different branch layout.

To explain it in a non-scientific way, let's take an example:

1. A source repo contains branches "master", "dev" and "release".

   It also contains two tags, "v1" and "v2".

   The "HEAD" reference in that repository points to a branch "master".

2. When you clone this repo, your local clone will have:

   • The three remote-tracking branches: "origin/master", "origin/dev" and "origin/release".

   • The two tags, "v1" and "v2".

   • A local branch named "master" which points to the same commit the remote-tracking branch "origin/master" does.

3. If you now clone this clone the result will have:

   • A single remote-tracking branch "origin/master".

   • A single local branch "master".

   • The two tags, "v1" and "v2".

This might appear weird, but in fact this is explicitly stated in the manual page:

Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch -r), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch.

After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any (this is untrue when "--single-branch" is given; see below).

This default configuration is achieved by creating references to the remote branch heads under refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables.

So "clone" in git clone means that all the history is cloned (unless told otherwise) but the layout of branches is different.

The reasoning is this: exactly because Git is a distributed VCS, all branches in your non-bare repository are "yours" in the sense that you do work on them and only you decide how they get synchronized with the branches in other repostories, when and why.

So when you clone a repo "the normal way" Git:

• Only fetches the branches local to that repo: no remote-tracking branches are consdered.

  This is because the remote-tracking branches serve as bookmarks to the states of other repositories, and no work is done on them.

  To understand why Git behaves this way, consider that when you clone a Joe's repository most of the time you want Joe's work, not the stuff he fetched from whatever random repositories he communicated with.

• Turns all the fetched branches into remote-tracking branches in the resulting repo.

• Creates a single local branch and checks it out.

  This is merely a convenience which only adds to a possible confusion.

What to do

Well, git clone accepts a "--mirror" command-line option which produces a true copy of the origin repo but the resulting repo will be bare. Should you re-clone the resulting repo again using the "--mirror" command-line option, you will again get the true copy.

If you did a "normal" clone (which, I reckon, you did) you still are able to get everything from that repository but git clone won't cut it: you'll need to do git init followed by git remote add origin <url> followed by a specially crafted git fetch.

Exactly how to craft that git fetch, depends on what you really want to grab from the source repo, and where to put it. For a start, consider that the source repo now has "origin/master" and "master", and they might very well contain diverged histories.

Also note that cloning a non-bare repo using git clone --mirror will work but the result will not be very sensible as in this case git clone will dutifully copy all the branches—both local and remote-tracking—from the source repo verbatim, and remote-tracking branches in not something you typically expect to be present in a bare repo.

这篇关于Git克隆已经是克隆的存储库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！