git branch, fork, fetch, fusion, rebase et clone, quelles sont les différences?

Est-ce que quelqu’un peut m’aider à comprendre la différence entre une twig, une fourchette et un clone dans Git?

De même, qu’est-ce que cela signifie quand je fais un git fetch plutôt qu’un git pull ?

rebase veut dire rebase en comparaison de la merge ?

Comment puis-je écraser des individus qui s’engagent ensemble?

Comment sont-ils utilisés, pourquoi sont-ils utilisés et que représentent-ils?

Comment intervient GitHub?

Un clone est simplement une copie d’un référentiel. En apparence, son résultat est équivalent à svn checkout , où vous téléchargez le code source depuis un autre référentiel. La différence entre les VCS centralisés comme Subversion et les DVCS comme Git est que dans Git, lorsque vous clonez, vous copiez en fait l’intégralité du référentiel source, y compris l’historique et les twigs. Vous avez maintenant un nouveau référentiel sur votre machine et tous les commits que vous faites vont dans ce référentiel. Personne ne verra de changement tant que vous n’aurez pas poussé ces commits vers un autre référentiel (ou l’original) ou jusqu’à ce que quelqu’un s’en tire de votre référentiel, s’il est accessible au public.

Une twig est quelque chose qui se trouve dans un référentiel. Conceptuellement, il représente un fil de développement. Vous avez généralement une twig principale, mais vous pouvez également avoir une twig sur laquelle vous travaillez sur certaines fonctionnalités xyz, et une autre pour corriger le bogue abc. Lorsque vous avez extrait une twig, tous les commits que vous effectuez restnt sur cette twig et ne sont pas partagés avec d’autres twigs tant que vous ne les avez pas fusionnées ou ne les avez pas rebaptisées sur la twig en question. Bien sûr, Git semble un peu bizarre quand il s’agit de twigs jusqu’à ce que vous regardiez le modèle sous-jacent de la manière dont les twigs sont implémentées. Plutôt que de l’expliquer moi-même (j’en ai déjà trop parlé, il me semble), je relierai l’explication de l’informatique sur la façon dont Git modélise les twigs et les commits, extraite du site Web de Git:

http://eagain.net/articles/git-for-computer-scientists/

Une fourchette n’est pas vraiment un concept Git, c’est plutôt une idée politique / sociale. En d’autres termes, si certaines personnes ne sont pas satisfaites de la manière dont un projet se déroule, elles peuvent prendre le code source et travailler elles-mêmes séparément des développeurs d’origine. Cela serait considéré comme une fourchette. Git simplifie la tâche car tout le monde a déjà sa propre copie “maîtresse” du code source, aussi simple que de couper les liens avec les développeurs du projet d’origine et n’exige pas l’exportation de l’historique depuis un référentiel partagé comme SVN .

EDIT: comme je n’étais pas au courant de la définition moderne de “fork” telle qu’elle est utilisée par des sites tels que GitHub, veuillez consulter les commentaires et la réponse de Michael Durrant ci-dessous pour plus d’informations.

Git

Ma réponse inclut github comme beaucoup de gens l’ont également demandé.

Référentiels locaux

git (localement) a un répertoire (.git) dans lequel vous engagez vos fichiers et ceci est votre “repository local”. Ceci est différent des systèmes comme svn où vous ajoutez et validez immédiatement le repository distant.

git stocke chaque version d’un fichier qui change en sauvegardant l’intégralité du fichier. Il est également différent de svn à cet égard, car vous pouvez accéder à n’importe quelle version individuelle sans la «recréer» au moyen de modifications delta.

git ne «verrouille» pas du tout les fichiers et évite ainsi la fonctionnalité de «locking exclusif» pour une édition (les anciens systèmes comme pvcs me viennent à l’esprit), donc tous les fichiers peuvent toujours être modifiés, même hors ligne. Il fait en fait un travail incroyable de fusion des modifications de fichiers (dans le même fichier!) Lors de retraits ou d’extractions / poussées vers un référentiel distant tel que github. La seule fois où vous devez effectuer des modifications manuelles (en fait, modifier un fichier), c’est si deux modifications impliquent la même ligne de code.


Branches

Les twigs vous permettent de conserver le code principal (la twig «maître»), de faire une copie (une nouvelle twig), puis de travailler dans cette nouvelle twig. Si le travail prend un certain temps ou si le maître reçoit beaucoup de mises à jour depuis la création de la twig, la fusion ou le rebasage (souvent préférable pour un meilleur historique et plus facile pour résoudre les conflits) contre la twig principale doit être effectué. Lorsque vous avez terminé, vous fusionnez les modifications apscopes dans la twig au référentiel maître. De nombreuses organisations utilisent des twigs pour chaque travail, qu’il s’agisse d’une fonctionnalité, d’un bug ou d’une tâche. D’autres organisations n’utilisent des twigs que pour les modifications majeures telles que les mises à niveau de version. Fork: Avec une twig, vous contrôlez et gérez la twig, alors qu’avec un fork, quelqu’un d’autre contrôle l’acceptation du code.
De manière générale, il existe deux approches principales pour faire des twigs. La première consiste à conserver la plupart des modifications sur la twig principale, en n’utilisant que des twigs pour des tâches plus importantes et plus longues, telles que les modifications de version lorsque vous souhaitez disposer de deux twigs pour des besoins différents. La seconde est que vous créez une twig pour chaque demande de fonctionnalité, correction de bogue ou tâche, puis décidez manuellement quand fusionner réellement ces twigs dans la twig principale. Bien que cela semble fastidieux, c’est une approche courante et c’est celle que j’utilise et que je recommande actuellement car cela permet de garder la twig principale plus propre et c’est le maître que nous promouvons en production. fusion de twigs.

La méthode standard pour amener une twig “in” à master est de faire une merge . Les succursales peuvent également être rebase pour «nettoyer» l’histoire. Cela n’affecte pas l’état actuel et est fait pour donner une histoire «plus propre». Fondamentalement, l’idée est que vous vous twigz à partir d’un certain point (généralement du maître). Depuis que vous êtes ramifié, «master» lui-même a progressé. Donc, ce serait plus propre si tous les changements effectués dans une twig étaient joués contre le maître le plus récent avec toutes ses modifications. Le processus est donc le suivant: enregistrer les modifications; obtenir le “nouveau” maître, puis réappliquer les modifications à nouveau contre cela. Sachez que rebase, tout comme la fusion, peut entraîner des conflits que vous devez résoudre manuellement (modifier).

Une «ligne direcsortingce» à noter: ne rebase que si la twig est locale et que vous ne l’avez pas encore poussée à distance! Ceci est principalement dû au fait que le rebasage peut modifier l’histoire que d’autres personnes voient et qui peut inclure leurs propres commits.

Suivi des twigs

Ce sont les twigs nommées origin / branch_name (par opposition à simplement branch_name). Lorsque vous poussez et tirez le code vers / depuis des référentiels distants, c’est en fait le mécanisme par lequel cela se produit. Par exemple, lorsque vous lancez une twig appelée “building_groups”, votre twig passe d’abord à origin / building_groups, puis à la firebase database distante (en fait, c’est une simplification excessive, mais assez bonne pour le moment). De même, si vous effectuez une git fetch building_groups le fichier récupéré est placé dans votre twig origin / building_groups. Vous pouvez alors choisir de fusionner cette twig dans votre copie locale. Notre pratique est de toujours faire une recherche git et une fusion manuelle plutôt qu’une simple extraction git (qui fait les deux en une étape).

Fetch chercher de nouvelles twigs.

Obtenir de nouvelles twigs: Au point initial d’un clone, vous aurez toutes les twigs. Cependant, si d’autres développeurs ajoutent des twigs et les envoient sur la télécommande, il doit y avoir un moyen de «connaître» ces twigs et leurs noms afin de pouvoir les supprimer localement. Cela se fait via un git fetch qui récupérera toutes les twigs nouvelles et modifiées dans le référentiel local en utilisant les twigs de tracking (par exemple origine /). Une fois git branch --remote , on peut git branch --remote pour lister les twigs de suivi et git checkout [branch] pour basculer vers une git checkout [branch] donnée.

Fusion

La fusion est le processus consistant à combiner des modifications de code provenant de différentes twigs ou de différentes versions de la même twig (par exemple, lorsqu’une twig locale et une télécommande sont désynchronisées). Si quelqu’un a développé un travail dans une twig et que le travail est terminé, prêt et testé, il peut être fusionné dans la twig principale. Ceci est fait par git checkout master pour passer à la twig master , puis git merge your_branch . La fusion réunira tous les différents fichiers et même les différentes modifications apscopes aux mêmes fichiers . Cela signifie qu’il va réellement changer le code à l’intérieur des fichiers pour fusionner toutes les modifications. Lors de la checkout de master il est également recommandé de faire un git pull origin master pour fusionner la dernière version du maître distant dans votre maître local. Si le maître distant a changé, c.-à-d. moved forward , vous verrez des informations qui reflètent cela pendant cette opération. Si tel est le cas (maître modifié), il vous est conseillé de git checkout your_branch et de le rebase pour que vos modifications soient réellement “relues” sur le “nouveau” maître. Ensuite, vous continuez à mettre le maître à jour comme indiqué dans le paragraphe suivant.

S’il n’y a pas de conflit, les nouvelles modifications seront ajoutées à master. S’il y a des conflits, cela signifie que les mêmes fichiers ont des modifications autour de lignes de code similaires qu’il ne peut pas fusionner automatiquement. Dans ce cas, git merge new_branch indiquera qu’il y a des conflits à résoudre. Vous les «résolvez» en éditant les fichiers (qui comporteront les deux modifications), en sélectionnant les modifications souhaitées, en supprimant littéralement les lignes des modifications que vous ne souhaitez pas, puis en enregistrant le fichier. Les modifications sont marquées par des séparateurs tels que ======== et <<<<<<<<

Une fois que vous avez résolu tous les conflits, vous devrez à nouveau git add et git commit pour continuer la fusion (vous recevrez des commentaires de git pendant ce processus pour vous guider). Lorsque le processus ne fonctionne pas correctement, vous constaterez que git merge --abort est très pratique pour réinitialiser les choses.

Réorganisation interactive et écrasement / réorganisation / suppression des commits

Si vous avez fait du travail dans de nombreuses petites étapes, par exemple si vous engagez chaque jour du code en tant que «work-in-progress», vous pouvez «écraser» ces petits commits dans des commits plus importants. Cela peut être particulièrement utile lorsque vous souhaitez effectuer des revues de code avec des collègues. Vous ne voulez pas relire toutes les "étapes" que vous avez sockets (via des commits), vous voulez simplement dire que voici l'effet final (diff) de toutes mes modifications pour ce travail dans une validation. Le facteur clé à évaluer pour déterminer s'il convient de procéder est de savoir si les validations multiples sont effectuées sur le même fichier ou sur plusieurs fichiers (mieux vaut écraser les commits dans ce cas). Ceci est fait avec l'outil de rebasage interactif. Cet outil vous permet d'écraser les commits, de supprimer les commits, de reformuler les messages, etc. Par exemple, git rebase -i HEAD~10 Notez qu'un ~ NOT a - affiche les éléments suivants:
rebasage interactif à Git Soyez prudent et utilisez cet outil avec précaution. Faites un squash / supprimer / réorganiser à la fois, quittez et enregistrez cette validation, puis entrez à nouveau l'outil. Si les commits ne sont pas contigus, vous pouvez les réorganiser (puis les écraser au besoin). Vous pouvez également supprimer des commits ici, mais vous devez vraiment être sûr de ce que vous faites lorsque vous le faites!

Fourches

Il existe deux approches principales pour la collaboration dans les référentiels git. La première, détaillée ci-dessus, est directement via les twigs que les gens tirent et poussent depuis / vers. Ces collaborateurs ont leurs clés ssh enregistrées avec le référentiel distant. Cela leur permettra de passer directement à ce référentiel. L'inconvénient est que vous devez maintenir la liste des utilisateurs. L'autre approche - forking - permet à quiconque de «faire un saut» du repository, en faisant essentiellement une copie locale dans son propre compte de repository git. Ils peuvent alors apporter des modifications et, une fois terminé, envoyer une requête de type "pull" (en réalité, il s'agit plutôt d'une "push" et d'une requête "pull" pour le responsable du repository) pour que le code soit accepté.
Cette seconde méthode, utilisant des forks, n'exige pas que quelqu'un maintienne une liste d'utilisateurs pour le référentiel.


Github

github (un référentiel distant) est une source distante que vous poussez et transférez normalement vers les modifications validées si vous avez (ou y êtes ajouté) un tel référentiel, de sorte que les modifications locales et distantes sont en réalité assez distinctes. Une autre façon de penser à un référentiel distant est que c'est une structure de répertoire .git qui réside sur un serveur distant.

Lorsque vous "fourchette" - dans l'interface Web du navigateur Web github, vous pouvez cliquer sur entrer la description de l'image ici - vous créez une copie ('clone') du code dans votre compte github. La première fois que vous le faites, cela peut être un peu subtil, alors assurez-vous de regarder sous quel référentiel une base de code est répertoriée - soit le propriétaire d'origine ou «forked from» et vous, par exemple entrer la description de l'image ici
Une fois que vous avez la copie locale, vous pouvez apporter les modifications souhaitées (en les tirant et en les poussant vers un ordinateur local). Lorsque vous avez terminé, vous soumettez une demande d’achat au propriétaire / administrateur du référentiel d’origine (ça sonne bien, mais en fait, il vous suffit de cliquer dessus: - entrer la description de l'image ici ) et ils le "tirent"
Il est plus courant pour une équipe travaillant ensemble sur le code de «cloner» le référentiel (cliquez sur l’icône «copie» sur l’écran principal du référentiel). Ensuite, tapez localement git clone [paste] Ceci vous mettra en place localement et vous pourrez également pousser et tirer vers l'emplacement de github (partagé).

Des clones

Comme indiqué dans la section sur github, un clone est une copie d'un référentiel. Lorsque vous avez un référentiel distant, vous exécutez la commande git clone sur son URL et vous obtenez alors une copie locale ou un clone du référentiel. Ce clone a tout , les fichiers, la twig principale, les autres twigs, tous les commits existants, tout le shebang. C'est ce clone que vous ajoutez et que vous validez, puis le repository distant lui-même est ce à quoi vous vous engagez. C'est ce concept local / distant qui fait de git (et des systèmes similaires à Mercurial) un système DVCS ( Dissortingbuted Version Control System) par opposition aux systèmes de version de code plus classiques tels que SVN, PVCS, CVS, etc. vous vous engagez directement dans le référentiel distant.

Visualisation

La visualisation des concepts de base peut être vue à
http://marklodato.github.com/visual-git-guide/index-en.html et
http://ndpsoftware.com/git-cheatsheet.html#loc=index

Si vous voulez un affichage visuel de la façon dont les changements fonctionnent, vous ne pouvez pas battre l'outil visuel gitg (gitx for mac) avec une interface graphique que j'appelle «la carte du métro» (en particulier London Underground). quoi, comment les choses changent, divergent et fusionnent, etc.

Vous pouvez également l'utiliser pour append, valider et gérer vos modifications!

interface gitg / gitx

Bien que gitg / gitx soit relativement minimal, au cours des 2-3 dernières années (2009-2012), le nombre d'outils d'interface utilisateur graphique continue de s'étendre. De nombreux utilisateurs de Mac utilisent fork de gitx de brotherbard et pour Linux une excellente option est smart-git avec une interface intuitive et puissante:

interface graphique intelligente

Notez que même avec un outil graphique, vous allez probablement faire beaucoup de commandes sur la ligne de commande.
Pour cela, j'ai les alias suivants dans mon fichier ~ / .bash_aliases (appelé depuis mon fichier ~ / .bashrc pour chaque session de terminal:

 # git alias gst='git status' # Warning: gst conflicts with gnu-smalltalk (when used). alias gb='git branch' alias gco='git checkout' alias gcob='git checkout -b ' alias ga='git add ' alias gc='git commit' alias gg='git grep ' # A great very FAST search option, easier then `find` 

Enfin, 6 sauveteurs clés:

1) Vous vous trompez dans votre agence locale et vous voulez simplement revenir à ce que vous aviez fait la dernière fois que vous avez fait un pull:

 git reset --hard origin/master # You will need to be comfortable doing this! 

2) Vous commencez à apporter des modifications localement, vous éditez une demi-douzaine de fichiers et puis, oh merde, vous êtes toujours dans la twig maître (ou autre):

 git checkout -b new_branch_name # just create a new branch git add . # add the changes files git commit -m"your message" # and commit them 

3) Vous gâchez un fichier particulier dans votre twig actuelle et souhaitez simplement "réinitialiser" ce fichier (perdre les modifications) à la dernière fois que vous l'avez extrait du repository distant: git checkout your/directories/filename réinitialise le fichier (comme beaucoup de commandes git, il n'est pas bien nommé pour ce qu'il fait ici).

4) Vous faites des modifications localement, vous voulez vous assurer de ne pas les perdre pendant que vous faites une réinitialisation ou un rebit de git: je fais souvent une copie manuelle de tout le projet ( cp -r ../my_project ~/ ) lorsque Je ne suis pas sûr de pouvoir me perdre ou de perdre des changements importants.

5) Vous rebasez mais les choses se gâtent:

 git rebase --abort # To abandon interactive rebase and merge issues 

6) Ajoutez votre twig git à votre invite PS1 (voir https://unix.stackexchange.com/a/127800/10043 ), par exemple entrer la description de l'image ici
La twig est selenium_rspec_conversion

Voici l’image de Oliver Steele sur la manière dont tout cela s’articule:

entrer la description de l'image ici

Juste pour append aux autres, une note spécifique au forking.

C’est bien de se rendre compte que techniquement, cloner le repo et forger le repo sont la même chose. Faire:

 git clone $some_other_repo 

et vous pouvez vous tapoter dans le dos – vous venez juste de faire un autre repository.

Git, en tant que VCS, est en fait tout au sujet du clonage . En dehors de la simple “navigation” en utilisant l’interface utilisateur distante telle que cgit, il n’y a pas grand chose à voir avec le repo git qui n’implique pas le clonage du repo à un moment donné.

cependant,

  • quand quelqu’un dit que j’ai repo X , ils ont créé un clone du repo ailleurs avec l’intention de l’ exposer à d’autres, par exemple pour montrer des expériences, ou pour appliquer un mécanisme de contrôle d’access différent (par exemple, autoriser des personnes sans Accès Github mais avec un compte interne à la société pour collaborer.

    Faits que: le repo est probablement créé avec une autre commande que git clone , qu’il est probablement hébergé quelque part sur un serveur par opposition à l’ordinateur portable de quelqu’un, et a probablement un format légèrement différent (c’est un “repo nu”, c.-à-d. arbre) ne sont que des détails techniques.

    Le fait qu’il contienne très probablement différents ensembles de twigs, étiquettes ou commits est probablement la raison pour laquelle ils l’ont fait en premier lieu.

    (Ce que fait Github lorsque vous cliquez sur “fork”, est juste le clonage avec du sucre ajouté: il clone le repo pour vous, le place sous votre compte, enregistre le “forked from” quelque part, ajoute remote nommée “upstream” joue la belle animation.)

  • Quand quelqu’un dit que j’ai cloné repo X , cela signifie qu’il a créé un clone du repo localement sur son ordinateur portable ou de bureau, avec l’intention de l’étudier, de jouer avec lui, d’y consortingbuer ou de créer quelque chose à partir du code source.

L’avantage de Git est que cela rend tout cela parfaitement compatible: tous ces repos partagent la partie commune de la chaîne de validation de bloc , il est donc possible de fusionner en toute sécurité (voir note ci-dessous) tous ces repo.


Remarque: “en toute sécurité” tant que vous ne réécrivez pas la partie commune de la chaîne et que les modifications ne sont pas en conflit.

Fourche vs. Clone – deux mots qui signifient tous les deux copie

S’il vous plaît voir ce diagramme. (À l’origine de http://www.dataschool.io/content/images/2014/Mar/github1.png ).

 .-------------------------. 1. Fork .-------------------------. | Your GitHub repo | <-------------- | Joe's GitHub repo | | github.com/you/coolgame | | github.com/joe/coolgame | | ----------------------- | 7. Pull Request | ----------------------- | | master -> c224ff7 | --------------> | master -> c224ff7 (c) | | anidea -> 884faa1 (a) | | anidea -> 884faa1 (b) | '-------------------------' '-------------------------' | ^ | 2. Clone | | | | | | | | | | | 6. Push (anidea => origin/anidea) v | .-------------------------. | Your computer | 3. Create branch 'anidea' | $HOME/coolgame | | ----------------------- | 4. Update a file | master -> c224ff7 | | anidea -> 884faa1 | 5. Commit (to 'anidea') '-------------------------' (a) - after you have pushed it (b) - after Joe has accepted it (c) - eventually Joe might merge 'anidea' (make 'master -> 884faa1') 

Fourchette

  • Une copie sur votre repo distant (cloud) qui le relie à Joe’s
  • Une copie que vous pouvez ensuite cloner dans votre repo local et F *% $ – haut
  • Lorsque vous avez terminé, vous pouvez repasser à votre télécommande
  • Vous pouvez alors demander à Joe s’il veut l’utiliser dans son projet en cliquant sur pull-request

Cloner

  • une copie sur votre repo local (disque dur)