Qu'est-ce que "git remote add ..." et "git push origin master" ?

Question

Bien souvent, Git et Ruby on Rails semblent être magiques... comme dans le premier chapitre du livre Ruby on Rails 3 Tutorial, où il est question de Git :

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

Et cela dit simplement "ça fonctionne" sans trop expliquer ce que sont ces commandes, et commence à parler des branches. En faisant des recherches sur Internet, on trouve que git remote add sert à ajouter un "nom court", tel que origin, qui peut être n'importe quel nom, fonctionnant comme un alias vers une URL.

Et origin est en général le chemin où pointe le dépôt distant (voir http://git-scm.com/book/en/Git-Basics-Working-with-Remotes sous "Adding Remote Repositories").

Alors pourquoi l'URL n'est-elle pas git://git@github.com/peter/first_app.git, mais dans l'autre syntaxe -- quelle syntaxe est-ce? Pourquoi doit-elle se terminer par .git? J'ai essayé sans .git à la fin et ça fonctionne aussi. Si ce n'est pas .git, ça peut être quoi d'autre? Le git dans git@github.com semble être un compte utilisateur sur le serveur Git?

Aussi, pourquoi doit-on être si verbeux en utilisant git push origin master? Ne pourraient-ils pas être les valeurs par défaut origin et master? J'ai remarqué que la première fois, origin master est nécessaire, mais après une petite modification et un commit, alors git push suffit (pas besoin de origin master). Quelqu'un qui sait ce qui se passe pourrait-il donner des détails?

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

Answer 1

Git est comme Unix. Il est convivial, mais il est pointilleux sur ses amis. Il est aussi puissant et convivial qu'un pipeline shell.

Cela dit, une fois que vous comprenez ses paradigmes et 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. Qu'est-ce que git remote add ...?

   Comme vous le savez probablement, Git est un système de contrôle de version distribué. La plupart des opérations se font localement. Pour communiquer avec le monde extérieur, Git utilise ce qu'on appelle des "remotes". Il s'agit de dépôts autres que celui sur votre disque local dans lesquels vous pouvez push vos modifications (pour que d'autres les voient) ou pull (pour récupérer les modifications des autres). La commande git remote add origin git@github.com:peter/first_app.git crée un nouveau remote appelé origin situé à git@github.com:peter/first_app.git. Une fois que vous avez fait cela, dans vos commandes de push, vous pouvez push vers origin au lieu de taper l'URL complète.

2. Qu'est-ce que git push origin master?

   C'est une commande qui signifie "pousser les commits dans la branche locale nommée master vers le remote nommé origin". Une fois cela exécuté, tout ce que vous avez synchronisé avec origin sera envoyé au dépôt distant et d'autres personnes pourront les voir là-bas.

Maintenant, à propos des transports (c'est-à-dire ce que signifie git://). Les URLs des dépôts distants peuvent être de nombreux types (file://, https://, etc.). Git se repose simplement sur le mécanisme d'authentification fourni par le transport pour gérer les permissions et autres. Cela signifie que pour les URLs file://, il utilisera les permissions de fichiers Unix, etc. Le schéma git:// demande à Git d'utiliser son propre protocole de transport interne, qui est optimisé pour envoyer des ensembles de changements Git. Quant à l'URL exacte, elle est comme cela en raison de la façon dont GitHub a configuré son serveur Git.

Maintenant la verborragie. 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 master ici est un miroir local de la branche appelée foo sur le remote appelé bar". En langage Git, cela signifie que master suit bar/foo. Lorsque vous clonez pour la première fois, vous obtiendrez une branche appelée master et un remote appelé origin (à partir duquel vous avez cloné) avec le master local configuré pour suivre le master sur origin.

Une fois cela configuré, vous pouvez simplement dire git push et cela le fera. La commande plus longue est disponible si vous en avez besoin (par exemple, git push pourrait pousser vers le dépôt public officiel et git push review master peut être utilisée pour pousser vers un remote séparé que votre équipe utilise pour la révision du code). Vous pouvez définir votre branche comme étant une branche de suivi en utilisant l'option --set-upstream de la commande git branch.

J'ai trouvé que Git (contrairement à la plupart des autres applications que j'ai utilisées) est mieux compris de l'intérieur vers l'extérieur. Une fois que vous comprenez comment les données sont stockées et entretenues à l'intérieur du dépôt, les commandes et ce qu'elles font deviennent très clairs. Je suis d'accord avec vous sur le fait qu'il y a un certain élitisme parmi de nombreux utilisateurs de Git, mais j'ai également trouvé cela parmi les utilisateurs d'Unix autrefois, et cela en valait la peine de passer outre pour apprendre le système. Bonne chance !

Answer 2

Mise à jour : notez que la réponse actuellement acceptée perpétue un malentendu courant 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 remotes - comme un surnom pour l'URL d'un dépôt - est correct.

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

Les deux URLs que vous avez mentionnées indiquent que deux protocoles de transport différents doivent être utilisés. Celui commençant par git:// est pour le protocole Git, qui est généralement utilisé uniquement pour un accès en lecture aux dépôts. L'autre, git@github.com:peter/first_app.git, est l'une des différentes façons de spécifier l'accès à un dépôt via SSH - il s'agit de la "syntaxe de style scp" décrite dans la documentation. Le fait que le nom d'utilisateur dans la syntaxe de style scp soit git est dû à la façon dont GitHub identifie les utilisateurs - essentiellement ce nom d'utilisateur est ignoré, et l'utilisateur est identifié en fonction de la paire de clés SSH qu'il a utilisée pour s'authentifier.

Quant à la verbosité de git push origin master, vous avez remarqué qu'après le premier push, vous pouvez simplement faire git push. Cela est dû à une série de paramètres par défaut difficiles à mémoriser mais généralement utiles :)

• Si aucun remote n'est spécifié, le remote configuré pour la branche actuelle (dans remote.master.url dans votre cas) est utilisé. Si ce n'est pas configuré, alors origin est utilisé.
• Si aucune "refspec" (par exemple master, master:my-experiment, etc.) n'est spécifiée, Git a pour défaut de pousser chaque branche locale qui a le même nom qu'une branche sur le remote. Si vous avez simplement une branche appelée master en commun entre votre dépôt et celui du remote, cela reviendra au même que de pousser votre master vers le remote master.

Personnellement, comme j'ai tendance à avoir de nombreuses branches thématiques (et souvent plusieurs remotes), j'utilise toujours la forme suivante :

git push origin master

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

---

En réponse à vos commentaires sur l'une des autres réponses, j'ai l'impression que vous apprenez Git de manière très efficace de haut en bas - vous avez découvert que les paramètres par défaut fonctionnent, et votre question porte sur pourquoi ;) Pour être plus sérieux, Git peut être utilisé de manière aussi simple que SVN, mais savoir un peu sur les remotes et les branches vous permet de l'utiliser de manière beaucoup plus flexible et cela peut vraiment changer votre façon de travailler en mieux.

Votre remarque sur un cours d'un semestre me fait penser à ce que Scott Chacon a dit dans une interview de podcast - les étudiants apprennent à utiliser 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 comme Git et Mercurial sont désormais si importants, et si flexibles, qu'il serait utile d'enseigner des cours sur eux pour donner aux gens des bases solides.

À mon avis, avec git, cette courbe d'apprentissage en vaut vraiment la peine - travailler avec de nombreuses branches thématiques, les fusionner facilement, et les pousser et les tirer entre différents dépôts est fantastiquement utile une fois que vous avez confiance dans le système. C'est juste dommage que :

• La documentation principale de Git soit si difficile à comprendre pour les nouveaux arrivants. (Bien que je ferais valoir que si vous cherchez presque n'importe quelle question sur Git, des tutoriels utiles (ou des réponses Stack Overflow :)) apparaissent de nos jours.)
• Il y a quelques comportements étranges dans Git qui sont difficiles à changer maintenant parce que de nombreux scripts peuvent s'appuyer sur eux, mais qui sont déroutants pour les gens.

Answer 3

Jetez un œil à la syntaxe pour ajouter un dépôt distant.

git remote add origin 

Exemple:

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

Examinons la commande:

git remote est utilisé pour gérer vos serveurs centraux pour héberger vos dépôts Git.

Peut-être que vous utilisez GitHub pour vos trucs de dépôt central. Je vais vous donner un exemple et expliquer la commande git remote add origin

Supposons que je travaille avec GitHub et Bitbucket pour les serveurs centraux des dépôts Git et que j'ai créé des dépôts sur les deux sites Web pour mon projet first-app.

Maintenant si je veux pousser mes modifications vers ces deux serveurs Git, alors je vais devoir dire à Git comment atteindre ces dépôts centraux. Donc je devrai 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 (autant que possible pour moi de les appeler variables) gh_origin (gh pour GitHub) et bb_origin (bb pour Bitbucket) juste pour vous expliquer que nous pouvons appeler origin comme nous le voulons.

Maintenant après avoir apporté des modifications, je devrai envoyer (pousser) toutes ces modifications vers les dépôts centraux afin que d'autres utilisateurs puissent voir ces modifications. Donc j'appelle

Envoyer vers GitHub

git push gh_origin master

Envoyer vers Bitbucket

git push bb_origin master

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

Ces deux variables rendent ma vie plus facile

car chaque fois que j'ai besoin d'envoyer mes modifications de code, j'ai juste besoin d'utiliser ces mots au lieu de me souvenir ou taper l'URL correspondante.

La plupart du temps, vous ne verrez rien d'autre que origin car la plupart du temps vous n'aurez affaire qu'à un seul dépôt central comme GitHub ou Bitbucket par exemple.

Answer 4

1. Le .git à la fin du nom du référentiel n'est qu'une convention. En général, sur les serveurs Git, les dépôts sont conservés dans des répertoires nommés projet.git. Le client Git et le protocole respectent cette convention en testant projet.git lorsque seulement projet est spécifié.

2. git://git@github.com/peter/first_app.git n'est pas une URL Git valide. Les dépôts Git peuvent être identifiés et consultés via divers schémas d'URL spécifiés ici. git@github.com:peter/first_app.git est l'URL ssh mentionnée sur cette page.

3. Git est flexible. Il vous permet de suivre votre branche locale par rapport à presque n'importe quelle branche de n'importe quel référentiel. Bien que master (votre branche locale par défaut) suive origin/master (la branche distante par défaut) soit une situation courante, ce n'est pas universel. Souvent, vous ne voudrez pas le faire. C'est pourquoi le premier git push est si verbeux. Il indique à Git quoi faire avec la branche locale mastergit pull ou un git push.

4. La valeur par défaut pour git push et git pull est de travailler avec le distant de la branche actuelle. C'est une meilleure valeur par défaut que origin master. La manière 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 à franchir.

Answer 5

Ceci est une réponse à cette question (Export Heroku App to a new GitHub repo) qui a été marquée comme doublon de celle-ci et redirigée ici.

Je voulais dupliquer mon dépôt depuis Heroku vers un GitHub personnel pour afficher tous les commits, etc., que j'ai également faits sur Heroku. Importer un dépôt Git en utilisant la ligne de commande dans la documentation GitHub a été utile.