使用git init，git remote add，git fetch等等效于git clone? [英] What's the equivalent of git clone, using git init, git remote add, git fetch etc.?

问题描述

目前我无法从Bitbucket服务器克隆存储库，我我发现我仍然可以执行一系列git init，git remote add等操作，以在我的计算机上获取存储库. 我想确保我准确地产生了一个等同于克隆"的东西. 以下正确吗?

As currently I cannot clone repositories from a Bitbucket server, I've found I can still do a series of git init, git remote add etc. to get the repository on my computer. I would like to make sure I exactly produce the equivalent of a "clone". Is the following correct?

git init
git remote add origin -m master https://www.myserver.com/bitbucket/scm/proj/repo.git
# need to do git fetch twice, otherwise for some reason git branch -r 
# returns "warning: ignoring broken ref refs/remotes/origin/HEAD"
git fetch
git fetch
git branch -r
git checkout --track origin/master
git checkout --track origin/develop
git checkout --track origin/feature/myfeature
# (etc.. for all the branches I need to work with)

我也不确定git remote中的-m标志是否需要或可能有害.

I'm also not sure about the flag -m in git remote is needed or potentially harmful.

@jthill建议的一些调试信息:

Some debug info as suggested by @jthill :

存储库1

git ls-remote --symref origin HEAD
ref: refs/heads/master  HEAD
842163b275ade3ec317543ed3a645f537d719766        HEAD

存储库2

git ls-remote --symref origin HEAD
ref: refs/heads/master  HEAD
1a1044eef2d46a292305dfc10cf076a4cf1e9933        HEAD

推荐答案

就是这样.克隆是init，远程添加和提取部分，之后您可以例如git checkout master甚至在创建本地ref和git之前都会对其进行设置并自动跟踪远程对象，因为该顺序非常普遍. -m只是绕过了bitbucket存储库作为其自己的主分支的内容，并告诉本地git您想要的内容，如果master是您想要的，那就是您想要的.

That's it. The clone is the init, remote add and fetch part, after that you can e.g. git checkout master even before creating the local ref and git will set it up and auto-track the remote because that sequence is so common. The -m just bypasses what that bitbucket repo has as its own main branch and tells the local git what you want as yours, if master is what you want, it's what you want.

因此，据我所知，-m应该应该"，以避免起源HEAD发生任何错误配置，并且第二次提取应该"是没有必要的.如果您将git ls-remote --symref origin HEAD的结果包括在内，则可能可以确定导致问题的原因，但是我认为没有什么意义，您已经找到了解决方法.

So the -m "should", near as I can figure, avoid whatever misconfiguration is going on with the origin's HEAD, and the second fetch "shouldn't" be necessary. If you'll include the results of git ls-remote --symref origin HEAD it'll probably be possible to identify what's causing the trouble, but I don't see much point, you've got a workaround.

这篇关于使用git init，git remote add，git fetch等等效于git clone?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！