Share
En termes simples, un référentiel distant n’est pas le vôtre. Il peut s'agir d'un serveur central, d'un ordinateur personnel d'un autre développeur ou même de votre système de fichiers. Tant que vous pouvez y accéder depuis un protocole réseau quelconque, Git facilite incroyablement le partage de contributions avec d'autres référentiels..
Le rôle principal des référentiels distants est de représenter d'autres développeurs au sein de votre propre référentiel. En revanche, les branches ne devraient s'occuper que du développement du projet. C’est-à-dire qu’il ne faut pas donner à chaque développeur sa propre branche pour qu’il fournisse à chacun un référentiel complet et des réserves pour le développement de fonctionnalités..
Ce chapitre commence par couvrir la mécanique des télécommandes, puis présente les deux flux de travail les plus courants de la collaboration basée sur Git: le flux de travail centralisé et le flux de travail de l'intégrateur..
Semblable à branche de git, la git à distance La commande est utilisée pour gérer les connexions à d’autres référentiels. Les télécommandes ne sont rien de plus que des signets vers d'autres référentiels. Au lieu de saisir le chemin d'accès complet, elles vous permettent de le référencer avec un nom convivial. Nous verrons comment utiliser ces favoris dans Git Below..
Vous pouvez afficher vos télécommandes existantes en appelant le git à distance commande sans argument:
git à distance
Si vous n'avez pas de télécommandes, cette commande ne produira aucune information. Si vous avez utilisé Git Clone pour obtenir votre référentiel, vous verrez un origine éloigné. Git ajoute automatiquement cette connexion, en supposant que vous souhaiterez probablement interagir avec elle ultérieurement..
Vous pouvez demander un peu plus d’informations sur vos télécommandes avec le -v drapeau:
git à distance -v
Cela affiche le chemin complet du référentiel. La spécification des chemins distants est traitée dans la section suivante..
le git remote ajouter commande crée une nouvelle connexion à un référentiel distant.
git remote ajouter
Après avoir exécuté cette commande, vous pouvez accéder au référentiel Git à l’adresse suivante:
Git accepte de nombreux protocoles réseau pour spécifier l’emplacement d’un référentiel distant, y compris: fichier://, ssh: //, http: //, et sa coutume git: // protocole. Par exemple:
git remote ajoute un utilisateur ssh: //[email protected]/some-user/some-repo.git
Après avoir exécuté cette commande, vous pouvez accéder au référentiel à l’adresse suivante: github.com/some-user/some-repo.git en utilisant seulement un utilisateur. Depuis que nous avons utilisé ssh: // En tant que protocole, vous serez probablement invité à entrer un mot de passe SSH avant de pouvoir utiliser quoi que ce soit avec le compte. Cela fait de SSH un bon choix pour accorder un accès en écriture aux développeurs, alors que les chemins HTTP sont généralement utilisés pour donner un accès en lecture seule. Comme nous le verrons bientôt, il s'agit d'une fonctionnalité de sécurité pour les environnements distribués..
Enfin, vous pouvez supprimer une connexion à distance avec la commande suivante:
git remote rm
Les validations peuvent être l’unité atomique du contrôle de version basé sur Git, mais branches sont le support sur lequel les référentiels distants communiquent. Branches distantes agir comme les branches locales que nous avons couvertes jusqu'à présent, sauf qu'elles représentent une branche dans le référentiel de quelqu'un d'autre.
Une fois que vous avez téléchargé une branche distante, vous pouvez l'inspecter, la fusionner et l'étendre comme toute autre branche. Cela donne une courbe d'apprentissage très courte si vous comprenez comment utiliser les branches localement.
Le fait de télécharger des branches depuis un autre référentiel est appelé aller chercher. Pour récupérer une branche distante, vous pouvez spécifier le référentiel et la branche que vous recherchez:
aller chercher
Ou, si vous voulez télécharger chaque branche dans -r option de branche de git:
branche git -r
Cela vous donne une liste de branches qui ressemble à quelque chose comme:
origine / origine principale / origine d'une caractéristique / autre caractéristique
Les branches distantes sont toujours précédées du nom distant (origine/) pour les distinguer des branches locales.
Rappelez-vous, Git utilise des référentiels distants comme signets-pas de connexions en temps réel avec d'autres référentiels. Les branches distantes sont copies des branches locales d’un autre référentiel. En dehors de l'extraction réelle, les référentiels sont des environnements de développement complètement isolés. Cela signifie également que Git ne récupérera jamais automatiquement les branches pour accéder aux informations mises à jour. Vous devez le faire manuellement..
Mais c’est une bonne chose, car cela signifie que vous n’aurez pas à vous soucier constamment de la contribution de tous les autres tout en faisant votre travail. Ceci n’est possible que grâce au workflow non linéaire activé par les branches Git..
À toutes fins utiles, les branches distantes se comportent comme des branches en lecture seule. Vous pouvez en toute sécurité consulter leur historique et consulter leurs commits via git checkout, mais vous ne pouvez pas continuer à les développer avant de les intégrer à votre référentiel local. Cela a du sens si l’on considère le fait que les succursales distantes sont copies des commits d'autres utilisateurs.
le … La syntaxe est très utile pour filtrer l'historique des journaux. Par exemple, la commande suivante affiche toutes les nouvelles mises à jour de origine / maître qui ne sont pas chez vous maîtriser branche. C'est généralement une bonne idée de l'exécuter avant de fusionner les modifications afin de savoir exactement ce que vous intégrez:
git log master… origine / master
Si cela génère des commits, cela signifie que vous êtes derrière le projet officiel et que vous devriez probablement mettre à jour votre référentiel. C'est décrit dans la section suivante.
Il est possible de commander des succursales distantes, mais cela vous mettra dans une situation isolée TÊTE Etat. Ceci est sûr pour afficher les modifications d'autres utilisateurs avant de les intégrer, mais toutes les modifications que vous ajoutez seront perdues à moins que vous ne créiez un nouveau conseil de branche locale pour les référencer..
Bien entendu, le but de la récupération consiste à intégrer les branches distantes obtenues à votre projet local. Supposons que vous contribuiez à un projet open-source et que vous travailliez sur une fonctionnalité appelée quelque chose. En tant que projet "officiel" (généralement signalé par origine), vous voudrez peut-être incorporer ses nouveaux commits dans votre référentiel. Cela garantirait que votre fonctionnalité fonctionne toujours avec les développements à la pointe de la technologie..
Heureusement, vous pouvez utiliser exactement le même fusionner commande pour incorporer les changements de origine / maître dans votre branche de fonctionnalité:
git checkout certaines fonctionnalités git chercher origine git fusionner origine / maître
Comme votre histoire a divergé, il en résulte une fusion à trois, après quoi votre quelque chose branche a accès à la version la plus récente du projet officiel.
Accentsconagua
maîtriser dans une branche de fonctionnalité Cependant, en fusionnant fréquemment avec origine / maître le simple fait d’obtenir des mises à jour entraîne finalement une histoire jonchée de commits de fusion sans signification. En fonction de la précision avec laquelle votre fonctionnalité doit suivre le reste de la base de code, le changement de base peut constituer un meilleur moyen d'intégrer les modifications:
git checkout quelques fonctionnalités git chercher origine git rebase origine / master
Comme pour le changement de base local, cela crée une histoire parfaitement linéaire, sans commissions de fusion superflues:
maîtriser Rebaser / fusionner des branches distantes a exactement les mêmes compromis que ceux décrits dans le chapitre sur les branches locales.
Comme la séquence d’extraction / fusion est une occurrence courante dans le développement distribué, Git fournit une tirez commande comme raccourci pratique:
origine git pull / master
Cela récupère la branche principale de l'origine, puis la fusionne en une étape dans la branche actuelle. Vous pouvez également passer le --rebasement option à utiliser git rebase au lieu de fusionner.
Pour compléter le aller chercher commande, Git fournit également un pousser commander. Pousser c'est presque l'opposé de chercher, en ce que chercher des branches importées, tout en poussant des branches exportées vers un autre référentiel.
git push
La commande ci-dessus envoie le local git push crée un local branche. Par exemple, en exécutant Git Push Mary My-Feature dans votre référentiel local ressemblera à ce qui suit du point de vue de Mary (votre référentiel ne sera pas affecté par la poussée).
Remarquerez que mon long métrage est un local branche dans le référentiel de Mary, alors que ce serait un éloigné branche l'avait-elle allée chercher.
Cela fait pousser une opération dangereuse. Imaginez que vous développiez dans votre propre référentiel local, quand, tout à coup, une nouvelle branche locale apparaît de nulle part. Mais les référentiels sont supposés servir d’environnements de développement complètement isolés, alors pourquoi git push existe même? Comme nous le découvrirons sous peu, pousser est un outil nécessaire pour la maintenance des référentiels Git publics..
Maintenant que nous avons une idée de base de la manière dont Git interagit avec d'autres référentiels, nous pouvons discuter des flux de travaux réels pris en charge par ces commandes. Les deux modèles de collaboration les plus courants sont: le flux de travail centralisé et le flux de travail de l'intégrateur. Les utilisateurs de SVN et de CVS devraient être assez à l'aise avec le style de développement centralisé de Git, mais utiliser Git signifie que vous serez également en mesure de tirer parti de ses capacités de fusion très efficaces. Le flux de travail de l'intégrateur est un modèle de collaboration distribué typique et n'est pas possible dans des systèmes purement centralisés..
En lisant ces flux de travail, gardez à l'esprit que Git traite tous les référentiels comme des égaux. Il n'y a pas de référentiel "maître" selon Git comme avec SVN ou CVS. La base de code "officielle" est simplement une convention de projet. La seule raison pour laquelle il est référentiel officiel est que origine points distants.
Chaque modèle de collaboration implique au moins un Publique référentiel qui sert de point d'entrée pour plusieurs développeurs. Les référentiels publics ont la seule contrainte d'être nu-ils ne doivent pas avoir de répertoire de travail. Cela empêche les développeurs d'écraser accidentellement le travail des autres git push. Vous pouvez créer un référentiel nu en passant le --nu option de git init:
git init --bare
Les dépôts publics ne devraient fonctionner que comme installations de stockage-pas d'environnements de développement. Cela se traduit par l’ajout d’un .git extension au chemin de fichier du référentiel, car la base de données du référentiel interne réside dans la racine du projet au lieu du .git sous-répertoire. Ainsi, un exemple complet pourrait ressembler à:
git init --bare some-repo.git
À part l'absence d'un répertoire de travail, un référentiel nu n'a rien de spécial. Vous pouvez ajouter des connexions à distance, y appuyer et en tirer de la manière habituelle..
Le flux de travail centralisé convient mieux aux petites équipes où chaque développeur a un accès en écriture au référentiel. Il permet la collaboration en utilisant un seul référentiel central, un peu comme le workflow SVN ou CVS. Dans ce modèle, tout les modifications doivent être partagées via le référentiel central, généralement stocké sur un serveur pour permettre la collaboration sur Internet.
Les développeurs travaillent individuellement dans leur propre référentiel local, complètement isolé de tous les autres. Une fois qu'ils ont terminé une fonctionnalité et qu'ils sont prêts à partager leur code, ils le nettoient, l'intègrent dans leur répertoire local. maîtriser, et poussez-le vers le référentiel central (par exemple., origine). Cela signifie également que chaque développeur a besoin d'un accès SSH au référentiel central..
Ensuite, tout le monde peut récupérer les nouveaux commits et les incorporer dans leurs projets locaux. Encore une fois, cela peut être fait avec une fusion ou une rebase, selon les conventions de votre équipe.
Il s’agit du processus essentiel des processus centralisés, mais il se heurte à des difficultés lorsque plusieurs utilisateurs tentent de mettre à jour simultanément le référentiel central. Imaginez un scénario dans lequel deux développeurs finissaient une fonctionnalité et la fusionnaient dans leur version locale. maîtriser, et essayé de le publier en même temps (ou presque).
Quiconque accède au serveur en premier peut forcer ses commits normalement, mais le deuxième développeur est bloqué par un historique différent et Git ne peut pas effectuer de fusion rapide. Par exemple, si un développeur nommé John poussait ses modifications juste avant Mary, nous verrions un conflit dans le référentiel de Mary:
La seule façon de faire la origineLe maître de (mis à jour par John) correspond à Mary maîtriser est de écraser John's commit. Évidemment, cela serait très mauvais, alors Git abandonne le push et génère un message d'erreur:
! erreur [refusée] master -> master (non-fast-forward): impossible d'insérer certaines références dans 'some-repo.git'
Pour remédier à cette situation, Mary doit se synchroniser avec le référentiel central. Ensuite, elle pourra pousser ses changements de la manière habituelle.
git chercher origine master git rebase origine / master git push origine master
En dehors de cela, le flux de travail centralisé est relativement simple. Chaque développeur reste dans son propre référentiel local, en tirant / poussant périodiquement vers le référentiel central pour que tout soit à jour. C'est un flux de travail pratique à configurer, car un seul serveur est requis et il exploite les fonctionnalités SSH existantes.
Le workflow de l’intégrateur est un modèle de développement distribué dans lequel tous les utilisateurs gèrent leurs Publique référentiel, en plus de leur dossier privé. Il existe en tant que solution aux problèmes de sécurité et d’évolutivité inhérents au flux de travail centralisé..
Le principal inconvénient du flux de travail centralisé est que chaque Le développeur doit pouvoir accéder à l’ensemble du projet. Cela convient si vous travaillez avec une petite équipe de développeurs de confiance, mais imaginez un scénario dans lequel vous travaillez sur un projet de logiciel à code source ouvert et où un étranger trouve un bogue, le corrige et souhaite incorporer la mise à jour projet principal. Vous ne voulez probablement pas lui donner un accès push au référentiel central, car il pourrait commencer à pousser toutes sortes de commits aléatoires et vous perdriez effectivement le contrôle du projet..
Mais ce que vous pouvez faire, c'est demander au contributeur de pousser les modifications à son propre référentiel public. Ensuite, vous pouvez extraire son correctif dans votre référentiel privé pour vous assurer qu'il ne contient pas de code non déclaré. Si vous approuvez ses contributions, tout ce que vous avez à faire est de les fusionner dans une branche locale et de les transférer dans le référentiel principal comme d’habitude. Vous êtes devenu un intégrateur, en plus d'un développeur ordinaire:
Dans ce flux de travail, chaque développeur n'a besoin que d'un accès push à son propre référentiel public. Le contributeur utilise SSH pour accéder à son référentiel public, mais l'intégrateur peut extraire les modifications via HTTP (protocole en lecture seule). Cela crée un environnement plus sécurisé pour tout le monde, même lorsque vous ajoutez d'autres collaborateurs:
Notez que l’équipe doit toujours se mettre d’accord sur un référentiel "officiel" unique, sans quoi les modifications seraient appliquées dans le désordre et tout le monde se désynchroniserait très rapidement. Dans le diagramme ci-dessus, "Your Public Repo" est le projet officiel..
En tant qu'intégrateur, vous devez surveiller plus de télécommandes que dans le flux de travail centralisé, mais cela vous donne la liberté et la sécurité nécessaires pour intégrer les modifications de tout développeur sans menacer la stabilité du projet..
En outre, le flux de travail de l'intégrateur ne dispose d'aucun point d'accès unique pouvant servir de point d'étranglement pour la collaboration. Dans les flux de travail centralisés, tout le monde doit être complètement à jour avant de publier les modifications, mais ce n'est pas le cas dans les flux de travail distribués. Encore une fois, ceci est un résultat direct du style de développement non linéaire rendu possible par l'implémentation de branches de Git..
Ce sont des avantages énormes pour les grands projets open source. Organiser des centaines de développeurs pour travailler sur un seul projet ne serait pas possible sans la sécurité et l'évolutivité de la collaboration distribuée..
Soutenir ces modèles de collaboration centralisés et distribués était tout ce que Git était censé faire. Le répertoire de travail, la scène, les commits, les branches et les télécommandes ont tous été spécifiquement conçus pour permettre ces flux de travail, et pratiquement tout dans Git tourne autour de ces composants..
Fidèle à la philosophie UNIX, Git a été conçu comme une suite d’outils interopérables, et non comme un seul programme monolithique. En continuant d'explorer les nombreuses fonctionnalités de Git, vous constaterez qu'il est très facile d'adapter des commandes individuelles à des flux de travail entièrement nouveaux..
Je vous laisse maintenant le soin d’appliquer ces concepts à des projets concrets, mais au moment où vous intégrez Git à votre flux de travail quotidien, n’oubliez pas que ce n’est pas une solution miracle pour la gestion de projet. Il s’agit simplement d’un outil de suivi de vos fichiers. Aucune connaissance intime de Git ne peut compenser les conventions aléatoires au sein d’une équipe de développement..
Cette leçon représente un chapitre de Git Succinctly, un eBook gratuit de l'équipe de Syncfusion.
