Quelle est la différence entre le clone et l'mkdir->cd->init->à distance-ajouter->tirez?
Après avoir configuré un repo sur Github, il semble y avoir deux façons de tirer ce repo dans un repo local.
Tout d'abord, je pourrais créer un répertoire, initialiser un repo vide, ajouter une télécommande, puis extraire les modifications de la télécommande.
> mkdir "exampleProject"
> cd "exampleProject"
> git init
> git remote add origin git@github.com:exampleUser/exampleProject.git
> git pull origin master
Deuxièmement, je pourrais cloner la télécommande.
> git clone git@github.com:exampleUser/exampleProject.git
Le clonage est-il juste un raccourci pour la version en 5 étapes ci-dessus ou fait-il autre chose? Vais-je rencontrer des difficultés si j'utilise une méthode sur l'autre?
1 réponses
Beaucoup de commandes, que ce soit des commandes git ou des programmes communs, font des choses en une seule ligne que vous pourriez autrement faire en dix. C'est toujours bon d'économiser du travail!
Cela dit, Vos pas sont proches, mais pas tout à fait les mêmes que ce que fait git clone. Je peux penser à quelques différences, tout à voir avec les branches:
Si, pour une raison quelconque, la tête de la télécommande estPas maître, le clone fera la bonne chose - vous donner une branche nommée la même que la télécommande, au lieu de maître. C'est rare, mais un bon détail à connaître.
Votre
git pullne créera aucune branche distante. Si la télécommande a plusieurs branches, le clone crée des branches distantesremotes/origin/foo,remotes/origin/bar, ... dans votre référentiel. Ungit fetch originprendrait soin de cela dans vos étapes énumérées.Vous n'avez pas non plus configuré votre branche master pour suivre les origines, ce que fait le clone. Vous pouvez ajouter ceci à vos étapes listées comme
git config branch.master.remote origin; git config branch.master.merge refs/heads/master. Ceci est très important - avec vos étapes, si vous avez maître extrait et vous tapez git pull, il ne saura pas quoi faire.
Il est possible que j'ai manqué quelque chose ou deux. En ce qui concerne les difficultés d'une manière ou d'une autre, même en supposant que vous aplanissez toutes les différences entre un clone par défaut et un "clone manuel", mon conseil serait de ne pas réinventer git clone:
C'est court. Pourquoi faire plus de travail?
Il a des options pratiques pour changer son comportement. Des choses comme
--sharedseraient vraiment difficiles à ajouter à votre liste commande.Il est garanti de faire la bonne chose maintenant et à l'avenir. Que faire si vous avez manqué un détail, comme ceux ci-dessus? Que faire si git a ajouté un paramètre de configuration global qui a affecté les clones? Vous devrez modifier vos commandes pour en tenir compte, mais git clone le saurait déjà.