Qu'est-ce que «git remote add…» et «git push origin master»?

Assez souvent, Git et Rails ressemble à de la magie ... comme dans le premier chapitre du livre Rails 3 Tutorial , il parle de Git:

git remote add origin git@github.com:peter/first_app.git
git push origin master

et il dit à peu près "ça marche juste" sans en dire trop sur ce qu'ils sont et commencer à parler de ramification. La recherche sur le net montre que cela git remote addconsiste à ajouter un "nom court", tel que origin, et il peut également s'agir de n'importe quel nom, qui est comme un alias à une URL. Et originest le chemin habituel d'où pointe le référentiel distant. (dans http://git-scm.com/book/en/Git-Basics-Working-with-Remotes sous "Ajout de référentiels distants")

Alors pourquoi l'URL n'est- git://git@github.com/peter/first_app.gitelle pas mais dans l'autre syntaxe - de quelle syntaxe s'agit-il? Pourquoi cela doit-il se terminer .git? J'ai essayé de ne pas utiliser .gità la fin et ça marche aussi. Sinon .git, quoi d'autre peut-il être? Le gitin git@github.comsemble être un compte utilisateur sur le serveur git?

Aussi, pourquoi doit-il être si verbeux à utiliser git push origin master? La valeur par défaut n'est-elle pas l'origine et le maître? J'ai trouvé que la première fois, le origin masterest nécessaire, mais après un petit montage et un commit, git pushc'est tout ce dont il a besoin (pas besoin origin master). Quelqu'un qui sait ce qui se passe peut-il donner des détails?

Parfois, cela ressemble à beaucoup de magie sans explication ... et parfois la personne qui l'utilise est si confiante et lorsqu'on lui demande pourquoi, ne peut pas l'expliquer et répondre avec quelque chose comme "c'est comme ça". Parfois très pratique et pragmatique. Ce n'est pas mal d'être pratique, mais probablement pas pratique au point de ne pas savoir ce qui se passe.

gitest comme UNIX. Convivial mais pointilleux sur ses amis. Il est à peu près aussi puissant et aussi convivial qu'un pipeline shell.

Cela dit, une fois que vous comprenez ses paradigmes et ses concepts, il a la même clarté zen que j'attends des outils de ligne de commande UNIX. Vous devriez envisager de prendre un peu de temps pour lire l'un des nombreux bons tutoriels git disponibles en ligne. Le livre Pro Git est un bon point de départ.

Pour répondre à votre première question.

1. Quel est git remote add ...

   Comme vous le savez probablement, gitest un système de contrôle de version distribué. La plupart des opérations se font localement. Pour communiquer avec le monde extérieur, gitutilise ce qu'on appelle remotes. Ce sont des référentiels autres que celui de votre disque local dans lesquels vous pouvez effectuer pushvos modifications (afin que d'autres personnes puissent les voir) ou pulldepuis (afin que vous puissiez obtenir d'autres modifications). La commande git remote add origin git@github.com:peter/first_app.gitcrée une nouvelle télécommande appelée originsituée à git@github.com:peter/first_app.git. Une fois que vous faites cela, dans vos commandes push, vous pouvez pousser vers originau lieu de taper l'URL entière.

2. Quel est git push origin master

   Il s'agit d'une commande qui dit "pousser les validations dans la branche locale nommée mastervers la télécommande nommée origin". Une fois que cela est exécuté, toutes les choses que vous avez synchronisées pour la dernière fois avec l'origine seront envoyées au référentiel distant et d'autres personnes pourront les voir là-bas.

Maintenant sur les transports (c'est-à-dire ce que git://) signifie. Les URL de référentiel distant peuvent être de plusieurs types ( file://, https://etc.). Git s'appuie simplement sur le mécanisme d'authentification fourni par le transport pour s'occuper des autorisations et des trucs. Cela signifie que pour les file://URL, il s'agira d'autorisations de fichiers UNIX, etc. Le git://schéma demande à git d'utiliser son propre protocole de transport interne, qui est optimisé pour envoyer des ensembles de modifications git. Quant à l'URL exacte, c'est comme ça à cause de la façon dont github a configuré son gitserveur.

Maintenant la verbosité. La commande que vous avez tapée est la commande générale. Il est possible de dire à git quelque chose comme "la branche appelée masterici est le miroir local de la branche appelée foosur la télécommande appelée bar". En git parler, cela signifie que les master pistes bar/foo . Lorsque vous clonez pour la première fois, vous obtiendrez une branche appelée masteret une télécommande appelée origin(d'où vous avez cloné) avec le maître local défini pour suivre le maître à l'origine. Une fois que cela est configuré, vous pouvez simplement dire git pushet ça le fera. La commande plus longue est disponible au cas où vous en auriez besoin (par exemple, elle git pushpeut être poussée vers le dépôt public officiel et git push review masterpeut être utilisée pour pousser vers une télécommande distincte que votre équipe utilise pour réviser le code). Vous pouvez définir votre succursale comme succursale de suivi à l'aide du--set-upstreamoption de la git branchcommande.

J'ai l'impression que git (contrairement à la plupart des autres applications que j'ai utilisées) est mieux compris de l'intérieur. Une fois que vous comprenez comment les données sont stockées et conservées dans le référentiel, les commandes et ce qu'elles font deviennent limpides. Je suis d'accord avec vous qu'il y a un certain élitisme parmi de nombreux gitutilisateurs, mais j'ai également constaté cela avec les utilisateurs UNIX il était une fois, et cela valait la peine de les dépasser pour apprendre le système. Bonne chance!

Mise à jour: notez que la réponse actuellement acceptée perpétue un malentendu commun sur le comportement de git push, qui n'a pas été corrigé malgré un commentaire le signalant.

Votre résumé de ce que sont les télécommandes - comme un surnom pour l'URL d'un référentiel - est correct.

Alors pourquoi l'URL ne git-elle pas: //git@github.com/peter/first_app.git mais dans l'autre syntaxe - de quelle syntaxe s'agit-il? Pourquoi doit-il se terminer par .git? J'ai essayé de ne pas utiliser .git à la fin et cela fonctionne aussi. Sinon .git, quoi d'autre peut-il être? Le git du débutant semble être un compte utilisateur sur le serveur git?

Les deux URL que vous avez mentionnées indiquent que deux protocoles de transport différents doivent être utilisés. Celui qui commence par git://est pour le protocole git, qui est généralement utilisé uniquement pour l'accès en lecture seule aux référentiels. L'autre,, git@github.com:peter/first_app.gitest l'une des différentes façons de spécifier l'accès à un référentiel via SSH - c'est la "syntaxe de style scp" décrite dans la documentation . Le nom d'utilisateur dans la syntaxe de style scp gitest dû à la façon dont GitHub traite l'identification des utilisateurs - essentiellement ce nom d'utilisateur est ignoré, et l'utilisateur est identifié en fonction de la paire de clés SSH qu'ils ont utilisée pour s'authentifier.

Quant à la verbosité de git push origin master, vous avez remarqué qu'après la première poussée, vous pouvez alors simplement le faire git push. Cela est dû à une série de valeurs par défaut difficiles à retenir mais généralement utiles :)

• Si aucune télécommande n'est spécifiée, la télécommande configurée pour la branche actuelle ( remote.master.urldans votre cas) est utilisée. Si ce n'est pas configuré, alors originest utilisé.
• S'il n'y a pas de "refspec" (par exemple master, master:my-experimentetc.) spécifié, alors git par défaut pousse toutes les branches locales qui ont le même nom qu'une branche sur la télécommande. Si vous avez juste une branche appelée masteren commun entre votre référentiel et la distante, ce sera la même chose que de pousser votre mastervers la télécommande master.

Personnellement, comme j'ai tendance à avoir plusieurs branches thématiques (et souvent plusieurs télécommandes) j'utilise toujours le formulaire:

git push origin master

... pour éviter de pousser accidentellement d'autres branches.

En réponse à vos commentaires sur l' un des autres réponses, il me semble que si on apprend au sujet git d'une manière descendante très efficace - vous avez découvert que les paramètres par défaut de travail, et votre question pose de savoir pourquoi;) Pour être plus sérieux, git peutêtre utilisé essentiellement aussi simplement que SVN, mais en savoir un peu sur les télécommandes et les branches signifie que vous pouvez l'utiliser de manière beaucoup plus flexible et cela peut vraiment changer votre façon de travailler pour le mieux. Votre remarque sur un cours de semestre me fait penser à quelque chose que Scott Chacon a dit dans une interview en podcast - les étudiants apprennent toutes sortes d'outils de base en informatique et en génie logiciel, mais très rarement le contrôle de version. Les systèmes de contrôle de version distribués tels que git et Mercurial sont maintenant si importants et si flexibles qu'il serait utile de leur donner des cours pour donner aux gens une bonne base.

À mon avis git, avec , cette courbe d'apprentissage en vaut vraiment la peine - travailler avec de nombreuses branches de sujets, les fusionner facilement et les pousser et les déplacer entre différents référentiels est incroyablement utile une fois que vous avez confiance en le système. Il est juste dommage que:

• La documentation principale de git est si difficile à analyser pour les nouveaux arrivants. (Bien que je soutienne que si vous recherchez Google pour presque n'importe quelle question git, du matériel didactique utile (ou des réponses Stack Overflow :)) apparaît de nos jours.)
• Il y a quelques comportements étranges dans git qui sont difficiles à changer maintenant car de nombreux scripts peuvent s'appuyer sur eux, mais sont déroutants pour les gens.

Jetez un œil à la syntaxe pour ajouter un référentiel distant.

git remote add origin <url_of_remote repository>

Exemple:

git remote add origin git@github.com:peter/first_app.git

Disséquons la commande:

git remote ceci est utilisé pour gérer vos serveurs centraux pour l'hébergement de vos dépôts git.

Peut-être que vous utilisez Github pour votre contenu de référentiel central. Je vais vous donner un exemple et expliquer l' origine git add distance commande

Supposons que je travaille avec GitHub et BitBucket pour les serveurs centraux des référentiels git et que j'ai créé des référentiels sur les deux sites Web pour mon projet de première application .

Maintenant, si je veux pousser mes modifications sur ces deux serveurs git, je devrai dire à git comment accéder à ces référentiels centraux. Je vais donc devoir les ajouter,

Pour GitHub

git remote add gh_origin https://github.com/user/first-app-git.git

Et pour BitBucket

git remote add bb_origin https://user@bitbucket.org/user/first-app-git.git

J'ai utilisé deux variables (pour autant qu'il soit facile pour moi de les appeler variables) gh_origin (gh FOR GITHUB) et bb_origin (bb pour BITBUCKET) juste pour vous expliquer que nous pouvons appeler origine tout ce que nous voulons.

Maintenant, après avoir apporté quelques modifications, je devrai envoyer (pousser) toutes ces modifications aux référentiels centraux afin que les autres utilisateurs puissent voir ces modifications. Alors j'appelle

Pousser vers GitHub

git push gh_origin master

Pousser vers BitBucket

git push bb_origin master

gh_origin détient la valeur de https://github.com/user/first-app-git.git et bb_origin détient la valeur de https: //user@bitbucket.org/user/first-app-git.git

Ces deux variables me facilitent la vie

comme chaque fois que je dois envoyer mes modifications de code, je dois utiliser ces mots au lieu de me souvenir ou de taper l'URL pour le même.

La plupart du temps, vous ne verrez rien, sauf l' origine, car la plupart du temps, vous ne traiterez qu'avec un seul référentiel central comme Github ou BitBucket par exemple.

1. À .gitla fin du nom du référentiel est juste une convention. En règle générale, sur les serveurs git, les référentiels sont conservés dans des répertoires nommés project.git. Le client et le protocole git respectent cette convention en testant project.gitlorsque seul projectest spécifié.

2. git://git@github.com/peter/first_app.gitn'est pas une URL git valide. les référentiels git peuvent être identifiés et accessibles via divers schémas d'url spécifiés ici . git@github.com:peter/first_app.git est l' sshURL mentionnée sur cette page.

3. gitest flexible. Il vous permet de suivre votre branche locale contre presque toutes les branches de n'importe quel référentiel. Bien que le mastersuivi (de votre branche par défaut locale) origin/master(la branche par défaut distante) soit une situation courante, il n'est pas universel. Plusieurs fois, vous ne voudrez peut-être pas faire cela. C'est pourquoi le premier git pushest si bavard. Il indique à git quoi faire avec la masterbranche locale lorsque vous faites un git pullou un git push.

4. La valeur par défaut pour git pushet git pullest de travailler avec la télécommande de la branche actuelle. C'est un meilleur défaut que le maître d'origine. La façon dont git push détermine cela est expliquée ici .

git est assez élégant et compréhensible mais il y a une courbe d'apprentissage à parcourir.

Git remote add origin:

Il centralise votre code source dans les autres projets.Il est développé sur la base de Linux, open source complet et rend votre code utile aux autres utilisateurs de git.Nous l'appelons comme référence

Pousse votre code dans le référentiel git en utilisant l'url distante du hub git.