克隆和mkdir->cd->init->remote-add->pull有什么区别？
在 Github 上设置存储库后，似乎有两种方法可以将该存储库拉入本地存储库。
首先，我可以创建一个目录，初始化一个空白存储库，添加一个远程，然后从远程提取更改。
> mkdir "exampleProject"
> cd "exampleProject"
> git init
> git remote add origin [email protected]:exampleUser/exampleProject.git
> git pull origin master
其次，我可以克隆遥控器。
> git clone [email protected]:exampleUser/exampleProject.git
克隆只是上述 5 步版本的快捷方式还是还可以执行其他操作？如果我使用一种方法而不是另一种方法，我会遇到困难吗？
After setting up a repo on Github, there seems to be two ways to pull that repo into a local repo.
Firstly, I could create a directory, initialize a blank repo, add a remote and then pull changes from the remote.
> mkdir "exampleProject"
> cd "exampleProject"
> git init
> git remote add origin [email protected]:exampleUser/exampleProject.git
> git pull origin master
Secondly, I could clone the remote.
> git clone [email protected]:exampleUser/exampleProject.git
Is cloning just a shortcut for the 5 step version above or does it do anything else as well? Will I run into difficulty if I use one method over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
许多命令，无论是 git 命令还是常见程序，都可以在一行中完成原本可以用十行完成的事情。节省工作总是好的！
也就是说，您的步骤与 git clone 的操作很接近，但不完全相同。我可以想到一些差异，所有这些差异都与分支有关：
如果由于某种原因，远程的 HEAD 不是 master，克隆将做正确的事情 - 给你一个名为的分支与遥控器相同，而不是主控。这种情况很少见，但需要注意的一个很好的细节。
您的
git pull不会创建任何远程分支。如果远程有多个分支，则克隆会在您的存储库中创建远程分支remotes/origin/foo、remotes/origin/bar、...。git fetch origin将在您列出的步骤中处理该问题。您还没有设置主分支来跟踪源分支，而克隆则这样做。您可以将其添加到列出的步骤中，如 git configbranch.master.remote origin; git configbranch.master.merge refs/heads/master。这非常重要 - 按照您的步骤，如果您签出 master 并输入 git pull，它将不知道该怎么做。
我可能错过了一两件事。至于以某种方式遇到的困难，即使假设您消除了默认克隆和“手动克隆”之间的所有差异，我的建议也不是重新发明
git clone：很短。为什么要做更多的工作？
它有方便的选项来改变其行为。像
--shared这样的东西很难添加到列出的命令中。它保证现在和将来都会做正确的事情。如果您错过了像上面这样的细节怎么办？如果 git 添加了影响克隆的全局配置参数怎么办？您必须更改命令才能将其考虑在内，但 git clone 已经知道了。
A lot of commands, whether git commands or common programs, do things in one line you could otherwise do in ten. It's always good to save work!
That said, your steps are close to, but not entirely the same as, what
git clonedoes. I can think of a few differences, all to do with branches:If, for some reason, the remote's HEAD is not master, the clone will do the right thing - give you a branch named the same as the remote's, instead of master. This is rare, but a good detail to be aware of.
Your
git pullwon't create any remote branches. If the remote has several branches, the clone creates remote branchesremotes/origin/foo,remotes/origin/bar, ... in your repository. Agit fetch originwould take care of that in your listed steps.You also haven't set up your master branch to track origin's, which the clone does. You could add this to your listed steps as
git config branch.master.remote origin; git config branch.master.merge refs/heads/master. This is very significant - with your steps, if you have master checked out and you type git pull, it won't know what to do.It's possible I've missed a thing or two. As for difficulties one way or the other, even assuming you iron out all the differences between a default clone and a "manual clone", my advice would be not to reinvent
git clone:It's short. Why do more work?
It's got handy options to change its behavior. Things like
--sharedwould be really difficult to add to your listed commands.It's guaranteed to do the right thing now and in the future. What if you missed a detail, like the ones above? What if git added a global config parameter that affected clones? You'd have to change your commands to take it into account, but git clone would already know.