Qu'est-ce que "git remote add ..." et "git Push Origin master"?

Question

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

git remote add Origin git@github.com:peter/first_app.git git Push Origin master

et cela dit à peu près "ça marche" sans trop en dire et commencer à parler de branchement. La recherche sur le net montre que git remote add consiste à ajouter un "nom abrégé", tel que Origin, et il peut également s'agir de n'importe quel nom, qui ressemble à un alias pour une URL. Et Origin est le chemin habituel de l'emplacement du repo distant. (in http://git-scm.com/book/fr/Git-Basics-Working-with-Remotes sous "Ajouter des référentiels distants")

Alors pourquoi l'URL n'est-elle pas git://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, que peut-il être d'autre? La git dans git@github.com semble être un compte d'utilisateur sur le serveur git?

Aussi, pourquoi faut-il être si prolixe pour utiliser git Push Origin master? La valeur par défaut ne peut-elle pas être l'origine et le maître? J'ai trouvé que la première fois, le Origin master est nécessaire, mais après une petite modification et une validation, alors git Push est tout ce dont il a besoin (pas besoin de 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 tellement confiante. Lorsqu'on lui demande pourquoi, elle ne peut pas l'expliquer et répond 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 au point de ne pas savoir ce qui se passe.

Noufal Ibrahim · Accepted Answer

git est comme UNIX. Facile à utiliser mais difficile à propos de ses amis. C'est à peu près aussi puissant et convivial qu'un pipeline Shell.

Cela dit, une fois que vous avez compris ses paradigmes et ses concepts, il a la même clarté zen que celle à laquelle je m'attendais des outils en 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.

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 sont effectuées localement. Pour communiquer avec le monde extérieur, git utilise ce que l'on appelle remotes. Ce sont des référentiels autres que celui de votre disque local dans lequel vous pouvez Push mettre vos modifications (afin que les autres personnes puissent les voir) ou pull de (afin que vous puissiez obtenir d'autres modifications). La commande git remote add Origin git@github.com:peter/first_app.git crée une nouvelle télécommande appelée Origin située à git@github.com:peter/first_app.git. Cela fait, dans vos commandes Push, vous pouvez pousser vers Origin au lieu de taper l'URL complète.
Qu'est-ce que git Push Origin master

Il s'agit d'une commande qui dit "Poussez les commits dans la branche locale nommée master vers la télécommande nommée Origin". Une fois que cela est exécuté, tous les éléments que vous avez synchronisés en dernier avec Origin seront envoyés au référentiel distant et les autres personnes pourront les visualiser.

Parlons maintenant des transports (c.-à-d. Ce que git://) signifie. Les URL du 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 gérer les permissions et autres éléments. Cela signifie que pour les URL file://, il s'agira d'autorisations de fichiers UNIX, etc. Le schéma git:// demande à git d'utiliser son propre protocole de transport interne, optimisé pour l'envoi de changesets git. Pour ce qui est de l'URL exacte, c'est comme ça parce que github a configuré son serveur git.

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 master ici est un miroir local de la branche appelée foo sur la télécommande appelée bar". En général, cela signifie que master tracks bar/foo. Lorsque vous clonerez pour la première fois, vous obtiendrez une branche appelée master et une télécommande appelée Origin (d'où vous avez cloné) avec le maître local configuré pour suivre le maître sur Origin. Une fois que ceci est configuré, vous pouvez simplement dire git Push et le faire. La commande la plus longue est disponible au cas où vous en auriez besoin (par exemple, git Push pourrait envoyer au repo public officiel et git Push review master peut être utilisé pour pousser vers une télécommande séparée que votre équipe utilise pour réviser le code). Vous pouvez définir votre branche pour qu'elle soit une branche de suivi à l'aide de l'option --set-upstream de la commande git branch.

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 avez compris comment les données sont stockées et conservées dans le référentiel, les commandes et leur signification deviennent parfaitement claires. Je conviens avec vous qu'il existe un peu d'élitisme chez de nombreux utilisateurs git, mais j’ai aussi constaté qu’il était une fois avec les utilisateurs UNIX et qu’il valait la peine de les contourner pour apprendre le système. Bonne chance!

Mark Longair · Answer

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

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

Alors pourquoi l’URL n’est-elle pas git: //git@github.com/peter/first_app.git mais dans l’autre syntaxe - de quelle syntaxe s’agit-il? Pourquoi doit-il finir avec .git? J'ai essayé de ne pas utiliser .git à la fin et cela fonctionne aussi. Si ce n'est pas le cas, quoi d'autre peut-il s'agir? Le git au débutant semble être un compte d'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:// concerne le protocole git, qui est généralement utilisé uniquement pour un accès en lecture seule aux référentiels. L’autre, git@github.com:peter/first_app.git, est l’une des différentes manières 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 est git, en raison de la façon dont GitHub traite l'identification des utilisateurs - ce nom d'utilisateur est essentiellement ignoré, et l'utilisateur est identifié en fonction de la paire de clés SSH qu'ils s'authentifiaient.

En ce qui concerne 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 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 (dans remote.master.url dans votre cas) est utilisée. Si ce n'est pas configuré, alors Origin est utilisé.
Si aucun "refspec" (par exemple, master, master:my-experiment, etc.) n'est spécifié, alors git utilise par défaut toutes les branches locales portant le même nom qu'une branche de la télécommande. Si vous avez juste une branche appelée master en commun entre votre référentiel et celui distant, ce sera la même chose que de pousser votre master vers la master distante.

Personnellement, comme j'ai tendance à avoir plusieurs branches de sujets (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’une des autres réponses, j’ai l’impression que are apprend à propos de git de manière très efficace - vous avez découvert que les paramètres par défaut fonctionnent et votre question est demander pourquoi;) Pour être plus sérieux, git peut être utilisé essentiellement aussi simplement que SVN, mais en savoir plus sur les télécommandes et les branches signifie que vous pouvez l’utiliser beaucoup plus avec souplesse, ce qui peut réellement changer votre travailler pour le mieux. Votre remarque au sujet d'un cours semestriel 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 à présent si importants et si flexibles qu'il serait intéressant de leur donner des cours pour donner aux gens de bonnes bases.

Mon opinion est qu'avec git, cette courbe d'apprentissage en vaut absolument la peine: travailler avec de nombreuses branches de sujet, les fusionner facilement et les déplacer d'un répertoire à un autre est extrêmement utile une fois que vous êtes confiant avec le système. C'est juste dommage que:

La documentation principale de git est si difficile à analyser pour les nouveaux arrivants. (Bien que je dirais que si vous utilisez Google pour presque toutes les questions git, des didacticiels utiles (ou des réponses au débordement de pile :)) apparaissent de nos jours.)
Il y a quelques comportements étranges dans git qui sont difficiles à changer maintenant car de nombreux scripts peuvent les utiliser, mais sont source de confusion pour les utilisateurs.

anshul · Answer

Le .git à la fin du nom du référentiel n'est qu'une convention. Généralement, les référentiels sur les serveurs git sont conservés dans des répertoires nommés project.git. Le client et le protocole git respectent cette convention en testant project.git lorsque seulement project est spécifié.
git://git@github.com/peter/first_app.git n'est pas une URL valide de Git. Les dépôts git peuvent être identifiés et accessibles via différents schémas d'URL spécifiés ici . git@github.com:peter/first_app.git est l'URI ssh mentionnée sur cette page.
git est flexible. Il vous permet de suivre votre branche locale par rapport à presque toutes les branches d’un référentiel. Bien que master (votre branche par défaut locale), le suivi de Origin/master (la branche par défaut distante) soit une situation courante, il n’est pas universel. Bien souvent, vous ne voudrez peut-être pas faire cela. C'est pourquoi le premier git Push est si prolixe. Il indique à git quoi faire avec la branche locale master lorsque vous faites un git pull ou un git Push.
La valeur par défaut pour git Push et git pull est de fonctionner avec la télécommande de la branche actuelle. C'est un meilleur choix que Origin Master. La façon dont git Push détermine cela s’explique ici .

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

Mr. Suryaa Jha · Answer

Vous utilisez git peut-être que vous êtes programmeur. Si vous êtes un programmeur, vous pouvez comprendre ce que sont les variables!

Consultez 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

Laissez-nous disséquer la commande:

git remote Ceci est utilisé pour gérer vos serveurs centraux pour l'hébergement de vos référentiels git.

Peut-être utilisez-vous Github pour votre contenu de référentiel 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 référentiels git et que j'ai créé des référentiels sur les deux sites Web de mon projet first-app.

Maintenant, si je veux appliquer mes modifications aux 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 (dans la mesure où il est facile de les appeler variables) gh_Origin (gh FOR GITHUB) et bb_Origin (bb pour BITBUCKET) juste pour vous expliquer, nous pouvons appeler Origin tout ce que nous voulons .

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

Pousser sur 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 mémoriser ou de taper l'URL de la même manière.

La plupart du temps, vous ne verrez rien d'autre que Origin, car vous ne traiterez généralement qu'avec un seul référentiel central comme Github ou BitBucket, par exemple.

saikumarputta · Answer

Git remote ajoute son origine:

Il centralise votre code source par rapport aux autres projets. Il est développé sous Linux, Complète en open source et rend votre code utile aux autres utilisateurs de git.

Pousse votre code dans le référentiel git à l'aide de l'URL distante du hub git.