Quelle est la différence entre faire (après mkdir repoet cd repo):
git init
git remote add origin git://github.com/cmcculloh/repo.git
git fetch --all
git pull origin master
et
git clone git://github.com/cmcculloh/repo.git
Je veux dire, évidemment, l'un est plus court, mais à part ça, font-ils essentiellement la même chose?
Réponses:
Ils sont fondamentalement les mêmes, sauf que le clone créera des branches de suivi à distance supplémentaires, pas seulement maître. Consultez la page de manuel :
Clone un référentiel dans un répertoire nouvellement créé, crée des branches de suivi à distance pour chaque branche du référentiel cloné (visible à l'aide de git branch -r), et crée et extrait une branche initiale qui est dérivée de la branche actuellement active du référentiel cloné.
git cloneest de savoir comment obtenir une copie locale d'un référentiel existant sur lequel travailler. Il n'est généralement utilisé qu'une seule fois pour un référentiel donné, sauf si vous souhaitez en avoir plusieurs copies de travail. (Ou voulez obtenir une copie propre après avoir foiré votre copie locale ...)
git pull(ou git fetch+ git merge) est la façon dont vous mettez à jour cette copie locale avec de nouvelles validations à partir du référentiel distant. Si vous collaborez avec d'autres, c'est une commande que vous exécuterez fréquemment.
Comme le montre votre premier exemple, il est possible d'émuler git cloneavec un assortiment d'autres commandes git, mais ce n'est pas vraiment le cas qui git pullfait "fondamentalement la même chose" que git clone(ou vice-versa).
En langage profane, nous pouvons dire:
git clone signifie que vous faites une copie du référentiel dans votre système.
git fork signifie que vous copiez le référentiel sur votre compte Github.
git pull signifie que vous récupérez le dernier référentiel modifié.
git push signifie que vous renvoyez le référentiel après l'avoir modifié.
En termes simples:
git clonetélécharge et git pullest rafraîchissant.
clone : copie du référentiel du serveur distant sur votre machine locale.
pull : obtenez de nouveaux changements que d'autres ont ajoutés à votre machine locale.
Voilà la différence.
Le clone est généralement utilisé pour obtenir une copie de repo à distance.
Pull est utilisé pour afficher le code ajouté aux autres coéquipiers, si vous travaillez en équipe.
git clone est utilisé pour télécharger exactement ce qui fonctionne actuellement sur le référentiel du serveur distant et l'enregistrer dans le dossier de votre machine où ce projet est placé. Généralement, il n'est utilisé que lorsque nous allons télécharger le projet pour la première fois. Après cette traction, c'est la meilleure option.
git pull est essentiellement une opération (clone (téléchargement) + fusion) et est principalement utilisé lorsque vous travaillez en équipe. En d'autres termes, lorsque vous souhaitez les modifications récentes de ce projet, vous pouvez tirer.
Mlle Clone: J'obtiens une nouvelle copie au local.
M. Pull: Je l'ai déjà localement, je le mets juste à jour.
Miss Clone: Je peux faire ce que tu fais! Tu es juste mon sous-ensemble.
M. Pull: Idem!
Miss Clone: Non, vous ne créez pas. C'est ce que je fais:
Vous ne faites que le numéro 3, puis vous fusionnez, ce que je n'ai pas besoin de faire (le mien est frais).
Mr Pull: Pantalon Smarty, pas grave, je vais faire un "git init" d'abord! Ensuite, nous sommes les mêmes. De plus, j'ai la capacité supplémentaire de «fusion» sur le référentiel existant! Ce qui fait de moi la commande la plus utilisée dans Git;)
Créateurs Git: Tenez vos chevaux Mr Pull, si --bare ou --mirror est utilisé avec clone ou init, votre fusion ne se produira pas. Il reste en lecture seule.
Hmm, qu'est-ce qui manque pour voir la branche distante "4.2" quand je tire, comme je le fais quand je clone? Quelque chose n'est clairement pas identique.
tmp$ mkdir some_repo
tmp$ cd some_repo
some_repo$ git init
Initialized empty Git repository in /tmp/some_repo/.git/
some_repo$ git pull https://github.ourplace.net/babelfish/some_repo.git
:
From https://github.ourplace.net/babelfish/some_repo
* branch HEAD -> FETCH_HEAD
some_repo$ git branch
* master
contre
tmp$ rm -rf some_repo
tmp$ git clone https://github.ourplace.net/babelfish/some_repo.git
Cloning into 'some_repo'...
:
Checking connectivity... done.
tmp$ cd some_repo
some_repo$ git branch
* 4.2
Bien que la git fetchcommande récupère toutes les modifications sur le serveur que vous n'avez pas encore, elle ne modifiera pas du tout votre répertoire de travail. Il obtiendra simplement les données pour vous et vous permettra de les fusionner vous-même. Cependant, il existe une commande appelée git pullqui est essentiellement un git fetchimmédiatement suivi d'un git mergedans la plupart des cas.
En savoir plus: https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches#Pulling
Clone -: Il créera une copie exactement en double de votre projet de référentiel distant sur votre machine locale.
Tirer -: supposons que deux ou plus de deux personnes partagent le même référentiel. (Supposons que le nom d'une autre personne soit Syam) (Un référentiel est un endroit où votre projet existe dans Github) Donc, si Syam fait des changements dans le même projet dans son local et le pousse vers le référentiel distant Donc, quelles que soient les modifications que Syam a apportées, ces changements seront ne se reflète pas dans votre section locale. Donc, pour refléter ces nouveaux changements dans votre section locale, vous devez utiliser git pull. Dans l'ensemble, nous utilisons git pull pour mettre à jour le projet.
Donc, fondamentalement, nous n'utilisons git clone qu'une seule fois alors que nous utilisons git pull plusieurs fois.