Fermer

mars 11, 2020

10 techniques Git que vous devez savoir avant de rejoindre une équipe –


Utilisez-vous Git depuis un certain temps mais jamais en équipe? Connaissez-vous les bases de Git mais ne savez pas comment les grandes équipes utilisent Git au travail?

Dans cet article, je vais parler des techniques de base de Git que vous devez connaître avant de rejoindre un équipe. Je les ai répertoriés dans un ordre que vous suivriez logiquement pour contribuer à un référentiel, car l'importance de chaque étape est primordiale. Passons maintenant à la liste.

1. Clonage: mise en route en équipe

Si vous avez utilisé Git pour des projets personnels, vous ne pouvez avoir initialisé un projet à partir de zéro et ajouté à lui au fil du temps. Lorsque vous travaillez sur une base de code existante, la première étape consiste à cloner la base de code dans votre système local. Cela vous permet de travailler sur votre copie du référentiel sans aucune interférence avec d'autres modifications.

Pour cloner un référentiel, exécutez la commande git clone suivi du chemin d'accès au référentiel:

 git clone / chemin / vers / repo

Si votre source ne réside pas sur le même système, vous pouvez SSH sur un système distant et cloner également:

 git clone username @ remote_system_ip: / path / to / repo / on / remote

Si vous clonez à partir d'une source sur Internet, vous pouvez simplement ajouter l'URL:

 git clone https://github.com/sdaityari/my_git_project.git

Chaque fois que vous clonez un référentiel, vous avez le choix de plusieurs protocoles pour vous connecter à la source. Dans l'exemple GitHub ci-dessus, j'ai utilisé le protocole https .

2. Gestion des télécommandes dans Git

Une fois que vous avez cloné votre référentiel, il conserve toujours un pointeur vers la source. Ce pointeur est un exemple de télécommande dans Git. Une télécommande est un pointeur vers une autre copie du même référentiel. Lorsque vous clonez un référentiel, un pointeur origine est automatiquement créé qui pointe vers la source.

Vous pouvez vérifier une liste de télécommandes dans un référentiel en exécutant la commande suivante:

 git remove -v

Pour ajouter une télécommande, vous pouvez utiliser la commande git remote add :

 git remote add remote_name remote_address

Vous pouvez supprimer une télécommande à l'aide de la commande git remote remove :

 git remote remove remote_name

Si vous souhaitez modifier l'adresse d'une télécommande, vous pouvez utiliser la commande set-url :

 git remote set-url remote_name new_remote_address

3. Branchement dans Git

Le plus grand avantage de Git par rapport aux autres systèmes de contrôle de version est la puissance de ses branches. Avant de me lancer dans l'essentiel de la ramification, vous vous demandez peut-être ce qu'est une branche . Une branche est un pointeur vers une validation dans votre référentiel, qui à son tour pointe vers son prédécesseur. Par conséquent, une branche représente une liste de validations par ordre chronologique. Lorsque vous créez une branche, vous ne créez en fait qu'un nouveau pointeur vers une validation. Cependant, en substance, cela représente une nouvelle voie de développement indépendante.

Si vous avez travaillé sur votre propre projet, vous n’avez peut-être jamais consciemment utilisé des branches. Par défaut, Git utilise la branche master pour le développement. Tout nouveau commit est ajouté à cette branche.

La branche est nécessaire pour que Git puisse bifurquer des lignes de travail dans un projet. À la fois, il peut y avoir de nombreux développeurs qui travaillent sur une variété de problèmes différents. Idéalement, ces problèmes sont résolus dans différentes branches pour garantir la séparation logique du nouveau code jusqu'à la révision et la fusion du code.

Pour vérifier une liste de branches et la branche active actuelle, exécutez la commande suivante:

 git branch

Pour créer une nouvelle branche, exécutez la commande suivante:

 git branch new_branch

Même si Git crée une nouvelle branche, notez que votre branche active est toujours l'ancienne. Pour démarrer le développement dans une nouvelle branche, exécutez ce qui suit:

 git checkout new_branch

Pour créer une nouvelle branche et modifier la branche active, exécutez la commande suivante:

 git checkout -b new_branch

Pour renommer la branche actuelle, exécutez la commande suivante:

 git branch -m new_renamed_branch

Utilisez l'option -D pour supprimer une branche:

 git branch -D new_renamed_branch

Voici un guide détaillé sur la ramification dans Git .

4. Mettre à jour votre référentiel local: fusion

Bien que nous ayons vérifié les bases de la création de branches dans Git, la prochaine étape logique consiste à fusionner une branche dans votre branche de base lorsque vous avez fini de travailler sur un problème. Pour fusionner une branche, exécutez la commande suivante:

 git checkout base_branch
git merge new_branch

Bien que cela puisse sembler un processus facile, la fusion est potentiellement le processus le plus long dans Git, car il peut donner lieu à des conflits.

5. Gérer les conflits

Imaginez que vous travaillez sur un fichier dans une nouvelle branche. Après avoir validé les modifications, vous demandez à Git de fusionner votre nouvelle branche avec votre branche de base. Cependant, la même partie du même fichier dans la branche de base a été mise à jour depuis que vous avez créé la nouvelle branche. Comment Git décide-t-il des modifications à conserver et des modifications à supprimer?

Git essaie toujours de ne perdre aucune donnée lors d'un processus de fusion. Si les modifications apportées au même fichier ont été effectuées dans différentes parties du fichier, vous pouvez vous en sortir en conservant les deux ensembles de modifications. Toutefois, si Git n'est pas en mesure de décider des modifications à conserver, il déclenche un conflit.

Lorsqu'un conflit a été déclenché, l'exécution de git status sur votre référentiel affiche une liste des fichiers qui ont été modifiés dans les deux. les branches fusionnées. Si vous ouvrez un fichier avec un conflit, vous remarquerez le jeu de lignes suivant:

 <<<<<<< < HEAD
...
...
========
...
...
> >>>>>>> new_branch

La ​​partie du fichier entre <<<<<<<< HEAD et ======== contient ce code qui est présent dans la branche de base. Les lignes de code entre ======== et >>>>>>>> new_branch sont présentes dans la branche new_branch . Le développeur qui fusionne le code a la responsabilité de décider quelle partie du code (ou un mélange des deux parties) doit être incluse dans la fusion. Une fois édité, supprimez les trois ensembles de lignes affichés, enregistrez le fichier et validez les modifications.

6. Synchroniser les modifications avec la télécommande

Alors que nous avons expliqué comment valider le code dans de nouvelles branches et le fusionner avec la branche de base, voyons maintenant comment synchroniser le code avec la télécommande. Avant de pouvoir publier vos modifications sur la télécommande, vous devez mettre à jour votre copie locale du référentiel pour tenir compte des modifications qui peuvent s'être produites depuis votre dernière mise à jour. Pour mettre à jour les modifications à partir de la télécommande, exécutez la commande suivante:

 git pull remote remote_branch: local_branch

La ​​commande git pull télécharge d'abord les données de la télécommande, puis fusionne avec la branche locale comme spécifié dans la commande. Des conflits peuvent survenir lors de l'extraction de modifications à partir d'une télécommande également. Dans un tel cas, la dernière ligne d'un fichier de conflit contiendrait >>>>>>>> commit_hash au lieu de >>>>>>>> new_branch commit_hash serait le hachage d'identification du commit ajouté à votre branche.

Pour publier les modifications apportées à la télécommande après avoir fusionné avec le dernier code de la télécommande, utilisez la commande git push :

 git push remote local_branch: remote_branch

7. Git sur le cloud: Forking

Si votre équipe travaille sur le cloud, vous êtes initié à un concept supplémentaire appelé fork. Un fork est une copie du référentiel central du cloud sous votre nom d'utilisateur. Vous avez un accès en écriture à votre fork, qui est un endroit sûr pour pousser les modifications sans affecter le référentiel d'origine.

Cela affecte l'étape même technique que j'ai décrite ci-dessus. Vous clonez votre fork, donc l'origine de votre référentiel local pointe vers votre fork sur le cloud. Comment obtenez-vous les mises à jour à partir du dernier référentiel? Vous devez ajouter manuellement une télécommande, en amont qui pointe vers le référentiel d'origine.

Bien que vous puissiez facilement publier des modifications dans votre fork, comment obtenir le nouveau code accepté dans le référentiel d'origine? Cela nous amène à l'étape suivante.

8. Révision de code via des requêtes d'extraction

Une requête d'extraction est une demande de fusion de code d'une branche à une autre. C'est un concept qui s'est développé depuis que les services cloud pour Git sont devenus populaires. Une pull request résume la comparaison entre les deux branches en question et lance une discussion entre le développeur et les administrateurs de l'organisation.

 Une conversation sur GitHub

Une révision de code peut aboutir à plus de changements avant peut être fusionné. Lorsque les administrateurs sont satisfaits des modifications, il peut être fusionné avec le référentiel.

9. Connaître les flux de travail Git

Lorsque vous travaillez seul sur un seul projet, vous utilisez probablement une seule branche. Sans le savoir, vous adhérez au flux de travail centralisé ou tronc, où toutes les modifications sont apportées à une seule branche.

Le flux de travail suivant, plus complexe, est le flux de travail branche-fonctionnalité, où une seule branche est attribuée à chaque fonctionnalité ou bogue. réparer. Aucun développement ne se produit directement sur les branches de développement master ou .

Un flux de travail Git qui englobe un large éventail de situations est le flux de travail Gitflow . Il a des branches distinctes pour le développement, les fonctionnalités, les versions et les correctifs.

Voici un guide détaillé sur les flux de travail Git .

10. Gérer les fichiers volumineux: Git LFS

Bien que Git fasse un excellent travail de gestion des fichiers texte, il n'est pas en mesure de suivre les modifications des fichiers binaires et exécutables. Bien que vous puissiez ajouter de tels fichiers à Git, cela pourrait potentiellement entraîner une grande taille de référentiel avec une augmentation du nombre de validations.

La solution consiste à utiliser Git Large File Storage qui gère les gros fichiers binaires. fichiers via Git. Cet outil stocke ces fichiers sur le cloud et les remplace par des pointeurs de texte. Voici une implémentation de utilisant Git LFS pour suivre les fichiers de conception Photoshop .

Lectures complémentaires

Dans cet article, j'ai parlé de diverses techniques Git qui peuvent vous aider lorsque vous vous joignez à une équipe pour la première temps. J'espère que cela vous a aidé dans votre préparation pour l'avenir. Ai-je raté quelque chose? Faites-le moi savoir sur Twitter !

Pour une compréhension plus approfondie de Git, consultez ces ressources:

  • Jump Start Git : Un guide concis qui vous mettra au courant dans un
  • Professional Git : Une plongée plus profonde qui vous emmènera sur le chemin de la maîtrise de Git.






Source link