Git est un outil puissant pour le contrôle de version et possède une sorte de monopole dans ce domaine. Pour la plupart des tâches quotidiennes, Git peut être simple à utiliser grâce à la répétition des commandes. Cependant, il existe de nombreuses situations où vous avez besoin de plus que les bases. C’est pourquoi il existe de nombreuses commandes Git avancées qui vous permettront de passer à la vitesse supérieure.
Cela vous permettra également de vous familiariser avec des concepts Git que vous n’avez pas l’habitude de rencontrer. Par exemple, l’archivage par opposition à la validation des modifications, le rebasage et l’ajout de fichiers à votre zone de staging. Une fois que vous les aurez assimilés, vous constaterez peut-être que vous avez encore plus de valeur pour votre équipe.
Dans cet article de blog, nous vous présentons différentes commandes puissantes que vous souhaitez connaître. Cependant, pour les utiliser, vous devez disposer de certaines compétences, de certains concepts et de certaines informations. Voyons d’abord cela.
Conditions préalables recommandées
Bien que vous soyez capable d’apprendre les bases de Git et de comprendre certaines commandes intermédiaires, telles que git delete, vous avez besoin de plus dans votre boîte à outils pour gérer les commandes avancées.
Les conseils que nous partageons ici ne conviendront pas à un débutant en Git, donc si le contrôle de version, en général, est nouveau pour vous, nous vous recommandons de passer un peu de temps à utiliser les commandes de base sur une base quotidienne avant de chercher à en ajouter d’autres à votre répertoire.
En bref, voici une liste rapide des aspects que vous devez comprendre :
- Concepts de base de Git tels que les commits, les branches, les pull requests, etc.
- Familiarité avec les commandes de base de Git telles que
git add,git merge,git commit, etgit push. - Pour les tâches Git avancées, vous devez être capable de naviguer dans un terminal.
Il est utile d’avoir une expérience de travail avec Git dans un environnement d’équipe, car beaucoup de ces commandes peuvent avoir un impact significatif sur une base de code partagée. Par exemple, il se peut que vous n’utilisiez certaines de ces commandes que dans le cadre d’un poste à responsabilité. Cela signifie que vous devez être prudent et comprendre quand vous utilisez ces commandes.
Git avancé : 12 commandes puissantes à connaître
Dans la suite de cet article, nous allons aborder 12 commandes Git avancées qui vous permettront d’aller au-delà des bases et de vous transformer en magicien de Git. Commençons par une commande que vous utiliserez peut-être plus que d’autres.
1. Rebasing
Tout d’abord, rebasing est une commande Git puissante qui est une alternative à une pull request. Elle vous permet d’intégrer tous les nouveaux commits que vous faites après une divergence de branche dans une nouvelle branche et de placer les changements à l’extrémité de la base. Ceci est utile si vous voulez incorporer des changements d’une autre branche sans créer un commit de fusion pour quelque raison que ce soit.
Un cas d’utilisation courant du rebasing est lorsque vous travaillez sur une branche de fonctionnalités et que vous souhaitez incorporer des modifications de la branche principale sans créer de commit de fusion. Cela permet de garder l’historique de votre projet propre, bien que l’exécution soit plus longue et que vous puissiez voir plus d’erreurs lors d’une fusion.
Pour rebaser une branche, utilisez la commande git rebase. Voici un exemple où nous rebasons une branche sur une autre :
git checkout foo-branch
git rebase main
Vous pouvez également lister les commits que vous allez publier et vous donner la possibilité de les éditer à l’avance. Ainsi, vous pouvez écraser des commits, éditer des messages de commits, et plus encore. Vous pouvez utiliser les drapeaux --interactive ou --i pour effectuer un « rebasing interactif ».
git rebase --interactive <other-branch-name>En parlant de cela, l’écrasement des commits en un seul pour mettre de l’ordre dans l’historique des livraisons est un cas d’utilisation courant du rebasing. Cela peut rendre votre historique des livraisons plus facile à lire et à comprendre.
Pour faire cela lors d’un rebasing, vous devez suivre le drapeau avec le nombre de commits que vous souhaitez écraser, ce qui combinera les commits en un seul :
git rebase -i HEAD~3
Cela ouvrira une fenêtre interactive de rebase, semblable à une fenêtre de commit, où vous pourrez choisir et éditer les commits que vous souhaitez écraser :
Vous avez une liste de commits en haut de l’écran et une sélection de commandes en bas, ainsi que d’autres informations pertinentes. L’option par défaut est de pick un commit, ce qui le sélectionne comme celui que vous voulez utiliser sans aucun changement.
Cependant, il existe de nombreuses autres commandes pour vous aider à naviguer dans un rebasing. Par exemple, vous pouvez reformuler un commit ou regrouper plusieurs commits. Pour effectuer des modifications et utiliser les commandes, vous travaillerez avec l’éditeur de votre terminal. L’éditeur par défaut est souvent Vim, ce qui signifie que vous devez connaître cet éditeur.
L’étape finale consiste à enregistrer vos modifications, puis à les pousser vers la branche distante.
2. Reverting, Resetting et Unstaging
Git est réputé pour sa capacité à annuler les modifications. C’est un processus difficile en général, avec un penchant pour les erreurs. Cependant, si vous apportez des modifications à votre répertoire de travail ou à votre zone de stockage et que vous souhaitez les annuler, il existe quelques commandes Git qui peuvent vous aider.
En fait, Git vous donne des indications sur la manière d’annuler un fichier si vous exécutez une commande git status:
Ainsi, vous pouvez supprimer un commit de la branche courante et l’envoyer ailleurs facilement :
git reset HEAD <commit>
Cela a pour effet de faire reculer votre branche d’un commit, comme si vous supprimiez le dernier commit connu. Vous pouvez même avoir un cas d’utilisation où vous voulez réinitialiser une branche à son état d’origine. Ici, vous pouvez réinitialiser par rapport à l’origine distante – en utilisant git reset --hard origin/main par exemple. Cependant, notez que ces changements disparaîtront à jamais.
Bien que la commande git checkout soit une commande que vous utiliserez souvent et qu’elle soit considérée comme basique, vous pouvez également l’utiliser pour dépiler des fichiers avant un commit :
git checkout -- <filename>
Notez l’espace entre les tirets et l’espace réservé au nom de fichier. Ici, la commande déstabilise le fichier que vous spécifiez et supprime les modifications du répertoire de travail. Notez que cette commande supprimera toutes les modifications locales que vous apportez à un fichier. Vérifiez donc deux fois et trois fois que vous n’avez pas besoin de ces modifications non sauvegardées.
Vous pouvez également utiliser git revert pour les modifications apportées à un commit. Cependant, cela n’annule pas les modifications mais crée un nouveau commit basé sur l’annulation des modifications dans le précédent.
La principale différence réside dans le fait que la commande ne déplace aucun pointeur de référence vers le nouveau commit, mais conserve les anciens commits. Ceci est utile lorsque vous souhaitez annuler des modifications sans les supprimer de l’historique des commits.
La commande s’attend à recevoir une référence, et il est facile de revenir sur le dernier commit :
git revert HEAD
Cependant, vous disposez d’une plus grande marge de manœuvre pour restaurer et modifier les fichiers et les commits. Les deux prochaines entrées de cette liste de commandes Git avancées s’y intéresseront.
3. Restaurer les fichiers dans leur état par défaut
Avec Git, vous pouvez facilement restaurer un fichier à son état par défaut à l’aide d’une commande relativement nouvelle : git restore. En fait, vous devriez considérer cette commande comme un remplacement de git reset dans la plupart des circonstances, car elle offre beaucoup plus de puissance sous le capot. Par exemple, vous pouvez obtenir le même résultat avec git restore --staged <filename> qu’avec git reset HEAD.
La commande peut cependant faire plus : vous pouvez également restaurer les fichiers à leur état par défaut. Vous verrez comment procéder si vous exécutez également git status :
git restore <filename>
Cette commande supprimera les modifications du répertoire de travail comme si rien ne s’était passé. Comme pour git checkout -- <filename>, vous devez vous assurer que vous ne voulez pas des modifications locales, car elles disparaîtront à jamais.
4. Modifier les commits
Il y aura probablement de nombreuses fois où vous pousserez un commit et réaliserez ensuite que vous avez oublié d’inclure quelque chose d’important. Avec Git, vous pouvez facilement modifier le commit pour inclure les changements manquants.
Pour cela, vous devez suivre un processus spécifique :
- Tout d’abord, effectuez vos modifications dans les fichiers dont vous avez besoin pour le projet.
- Mettez-les en staging comme d’habitude en utilisant
git add. - Recommencez ces modifications dans la zone de staging en utilisant une commande différente pour effectuer la validation :
git commit --amend
Cela modifie le commit original avec le nouveau commit en utilisant votre zone de staging. Assurez-vous donc que vous n’avez pas besoin de l’ancienne version du commit, car elle sera perdue. Nous vous recommandons également d’utiliser le drapeau --amend avec les commits locaux plutôt qu’avec les commits distants, pour des raisons similaires à celles que nous abordons dans cet article.
Vous pouvez également utiliser git commit --amend pour éditer le message de commit uniquement avec la commande suivante :
git commit --amend -m "New commit message"
5. Journalisation de Git
L’utilisation du journal de Git est utile pour vous aider à comprendre l’historique d’un dépôt. Cependant, nous ne classerions pas la commande git log comme avancée. Au lieu de cela, vous pouvez utiliser diverses options pour filtrer la sortie en fonction de vos besoins :
git log
git log --decorate
git log --stat
Par exemple, décorer une entrée du journal affiche les noms de ref pour tous les commits affichés. L’option --stat affiche les insertions et les suppressions pour un commit :
Vous pouvez également utiliser d’autres options pour personnaliser la sortie du journal – appelée « commit limiting ». Par exemple, prenez les commandes suivantes :
git log --author=<author-name>
git log --grep=<pattern-string>
Ici, vous pouvez filtrer le journal en fonction de noms d’auteurs spécifiques ou de modèles de texte. En fait, vous pouvez combiner plusieurs options et drapeaux pour générer un journal dans un but précis. Prenez par exemple la commande suivante :
git log --oneline --author=<author-name> --since=<date> feature-temp
Cette commande recherche tous les commits de la branche feature-temp d’un auteur unique depuis une date spécifiée, puis l’imprime en utilisant des entrées sur une seule ligne. Notez que le paramètre <date> peut également être une chaîne de caractères :
--since=”Two weeks ago”
De même, si vous souhaitez rechercher un fichier spécifique au lieu d’une branche, vous pouvez exécuter :
git log --oneline --author=bartonfink --since=”5 days ago” -- readme.rm
Cette série d’exemples ne fait qu’effleurer la surface de ce que vous pouvez faire avec vos journaux, mais il y a beaucoup de possibilités pour trouver des commits exacts dans ces journaux en fonction de vos critères de recherche.
6. Hooks Git
Vous utilisez probablement des macros et d’autres scripts automatisés pour vous aider à exécuter du code. Git inclut également ce type de fonctionnalité sous la forme de hooks. Ces scripts s’exécutent automatiquement en réponse à certains événements, tels que les commits ou les pushes. Il existe également de nombreuses façons d’utiliser les hooks pour renforcer le formatage du code, exécuter des tests, et bien d’autres choses encore.
Il existe deux types de hooks : côté client et côté serveur :
- Les hooks côté client se déclenchent en fonction des actions locales telles que les commits et les fusions.
- Les hooks côté serveur se déclenchent en raison d’opérations sur le réseau. Cela peut être le cas lorsqu’un dépôt reçoit un commit poussé, parmi de nombreux autres exemples.
Git remplira toujours votre dépôt avec plusieurs exemples de hooks une fois que vous aurez lancé git init. Cependant, vous devez supprimer l’extension .sample pour pouvoir les utiliser :
Notez que vous ne pouvez exécuter qu’un seul type de hook à la fois, bien qu’il soit possible d’utiliser plusieurs scripts à la fois après un certain travail. Ainsi, les noms de vos fichiers doivent correspondre au type de hook que vous souhaitez utiliser en vous basant sur les exemples de scripts : pre-commit, update, et ainsi de suite.
Créer un hook Git
Pour créer un hook Git, vous devez créer un script exécutable dans le sous-répertoire .git/hooks sans extension. Il s’exécutera tant que vous l’ajouterez au dossier hooks.
Vous pouvez utiliser le langage de script de votre choix, à condition qu’il soit exécutable. Nous vous suggérons Ruby ou Python, mais vous pouvez utiliser Bash, Perl et bien d’autres. Tout ce que vous avez à faire ici est de changer le chemin de votre interpréteur par rapport au chemin par défaut de Bash :
#!/usr/bin/env python
À partir de là, vous pouvez écrire votre code normalement. Par exemple, voici un script prepare-commit en Python qui invite l’utilisateur à écrire de bons messages de commit :
#!/usr/bin/env python
import sys, os
path_commit_msg = sys.argv[1]
with open(commit_msg_filepath, 'w') as f:
f.write("# You’ll need to provide a better commit message than that, buddy!")
Bien que cela ne soit pas toujours nécessaire, nous vous recommandons de lancer chmod +x .git/hooks/<hook-name> à partir de la ligne de commande pour vous assurer que vous pouvez l’exécuter.
Dans l’ensemble, les hooks peuvent être un outil puissant pour automatiser les tâches répétitives et renforcer les bonnes pratiques au sein de votre équipe.
7. Références de commits
Dans Git, vous identifiez les commits par le hash de cryptage SHA-1. Bien qu’il soit possible de se référer aux commits par leur hachage complet, cela peut être fastidieux et source d’erreurs :
bc7623b7a94ed3d8feaffaf7580df3eca4f5f5ca
Au lieu de cela, Git propose plusieurs façons de faire référence aux commits en utilisant des noms plus courts et plus faciles à mémoriser. Par exemple, vous pouvez utiliser le nom d’une branche ou d’une balise. Prenons l’exemple d’une branche appelée « develop ». Voici un exemple dans lequel nous faisons référence au dernier commit de cette branche :
git diff develop..HEAD
Ceci montre les différences entre le dernier commit (HEAD) sur la branche « develop » et le commit actuel.
Vous pouvez également faire référence à un commit en fonction de sa position relative dans l’historique des commits. Par exemple, vous pouvez faire référence à deux commits avant le commit actuel en utilisant l’abréviation HEAD~2:
git diff HEAD~2..HEAD
Git propose également plusieurs autres façons de faire référence aux commits, comme l’utilisation du symbole « @ » pour faire référence à la branche actuelle ou l’utilisation du symbole « ^ » pour faire référence au parent d’une livraison. En utilisant ces abréviations, vous pouvez gagner du temps et éviter les erreurs lorsque vous travaillez avec des commits.
8. Stashing
Dans des circonstances normales, vous penseriez qu’il n’y a aucun moyen de stocker les modifications que vous apportez aux fichiers sans les livrer. l’archivage est le moyen de le faire de manière temporaire. C’est utile lorsque vous avez besoin de changer de branche ou de travailler sur une tâche différente, mais que vous ne voulez pas encore valider vos modifications.
Par exemple, si vous avez besoin de changer de branche pour travailler sur quelque chose au milieu du flux, vous pouvez stocker les changements dans la branche actuelle et extraire l’autre branche. À partir de là, vous pouvez travailler sur l’autre branche, puis livrer et pousser ces changements. Vous pouvez ensuite extraire et récupérer votre travail sur la branche d’origine.
Il existe deux façons de conserver les modifications :
git stash
Cette méthode stocke vos modifications dans une nouvelle réserve et ramène votre répertoire de travail à la dernière livraison HEAD (l’état dans lequel vous l’aviez avant d’apporter de nouvelles modifications). Vous pouvez lister les modifications en utilisant git stash list, et inspecter la réserve en utilisant git stash show. Cette dernière commande peut également accepter n’importe quel format accepté par git diff.
À partir de là, vous pouvez changer de branche ou travailler sur une autre tâche. Lorsque vous souhaitez récupérer vos modifications, exécutez la commande suivante :
git stash apply
Cette commande appliquera les dernières modifications cachées à votre répertoire de travail. Notez toutefois que vous pouvez toujours rencontrer des conflits si vous modifiez trop le fichier. Après tout, git stash est une solution temporaire au problème posé.
Vous pouvez également avoir plusieurs cachettes, et vous pouvez spécifier la cachette à appliquer en utilisant ce qui suit :
git stash apply stash@{n}
L’espace réservé {n} prend un nombre entier, et stash@{0} représente la dernière réserve. La documentation officielle de Git contient d’autres exemples de git stash.
9. Bisecting
Nous parions que tout le monde a déjà rencontré un bogue ou un problème sans savoir où commencer à chercher. Dans ce cas, la méthode « bisecting » peut vous aider à identifier rapidement le commit qui a introduit le problème.
En bref, la commande chasse les bogues en effectuant une recherche dans vos commits. Une fois qu’elle a trouvé le commit incriminé, elle vous le renvoie. La puissance de cette commande réside dans toutes les sous-commandes que vous pouvez utiliser.
Pour utiliser bisecting, vous devez d’abord lancer la commande git bisect start. Git vous amènera alors au premier commit de l’historique de votre projet.
A partir de là, vous devez indiquer si ce commit est bon ou mauvais en utilisant les commandes appropriées :
git bisect good
git bisect bad
Git vous amènera alors au commit suivant pour tester sa « qualité » Notez que vous pouvez également remplacer « good » par « old » et « bad » par « new » pour répondre à votre cas d’utilisation spécifique (bien que vous ne puissiez pas mélanger les termes)
À partir de là, vous pouvez continuer à marquer chaque commit comme bon ou mauvais jusqu’à ce que vous trouviez le commit qui a introduit le bogue. Cependant, vous n’avez pas besoin de parcourir chaque commit – vous pouvez spécifier des identifiants exacts pour aider à restreindre et à raccourcir votre recherche :
git bisect bad feature-test
Ici, il s’agit d’un nom de branche, mais il pourrait s’agir d’une révision spécifique utilisant un nombre entier, une référence de hachage, etc. Quoi qu’il en soit, une fois que vous avez chassé et trouvé le bogue, vous pouvez exécuter l’une des commandes suivantes pour revenir à votre dernier code :
git bisect reset
Comme pour toutes les commandes Git avancées de cette liste, il y a beaucoup plus à assimiler, et la documentation Git sera une lecture essentielle ici.
10. Comparer les branches
Notre article sur les références de commit parle de l’utilisation de git diff. Il est maintenant temps de regarder cela plus en détail. Vous vous retrouverez souvent avec plusieurs branches qui contiennent des changements différents. Git vous permet de comparer les différences entre deux branches en utilisant la commande git diff. En fait, vous pouvez l’utiliser de plusieurs manières, souvent en conjonction avec d’autres commandes, pour investiguer et analyser un dépôt.
La commande de base git diff vous donnera une vue d’ensemble des modifications. Cela ressemble beaucoup à la sortie d’une enquête de fusion de commit :
Cependant, vous pouvez obtenir des branches exactes, des hachages, et plus encore. Par exemple, pour comparer deux branches, vous exécutez la commande git diff branch1..branch2, et remplacez les espaces réservés :
git diff feature-branch pre-prod
Vous pouvez également comparer les différences entre votre branche actuelle et une autre branche :
git diff HEAD..pre-prod
Notez que l’utilisation de deux points ici renverra la différence entre les deux extrémités des branches. En revanche, l’utilisation de trois points renverra la différence entre l’ancêtre commun des deux branches et l’utilisera pour tester.
À l’instar de git log, vous pouvez nettoyer la sortie et affiner ce qu’elle renvoie. Par exemple, git diff --name-only branch1..branch2 ne vérifiera que les fichiers qui diffèrent et laissera de côté le contexte :
Vous pouvez trouver que la sortie est difficile à analyser, surtout si le « diff » est long. Dans ce cas, vous pouvez utiliser l’option --color-words:
Dans l’ensemble, git diff peut être aussi puissant que d’autres commandes, en particulier lorsque vous invoquez certaines options et que vous affinez les différences que vous obtenez.
11. Appliquer des commits individuels
Il peut arriver que vous souhaitiez appliquer un commit spécifique d’une branche à une autre sans fusionner les deux branches. Git vous permet de le faire en utilisant git cherry-pick. Vous devez l’utiliser avec précaution, mais vous pouvez trouver que git cherry-pick peut vous aider dans quelques scénarios.
Par exemple, si vous avez des branches de fonctionnalités périmées que vous ne fusionnez pas dans main ou trunk, vous pouvez utiliser une combinaison de commandes (comme git log) pour extraire les anciens commits pertinents et les réappliquer ailleurs.
Utilisez git log pour trouver la référence d’un commit. A partir de là, assurez-vous que vous êtes sur la branche dont vous voulez extraire une référence. Par exemple, supposons que vous vouliez récupérer le commit xxxxxaaaaaa dans la branche « trunk ». Tout d’abord, vérifiez votre branche…
git checkout trunk
…puis faites un cherry-pick de votre commit :
git cherry-pick xxxxxaaaaaa
Votre message de commit sera probablement périmé à de nombreuses occasions. Pour résoudre ce problème, vous pouvez passer l’option --edit à la commande. Cela vous permettra de fournir un nouveau message de commit avant la sélection.
12. La surcharge de ‘git add’
Pour notre dernière commande avancée de Git, nous allons vous montrer git add. Non, ce n’est pas une faute de frappe – cette commande fondamentale de Git possède une puissance surprenante sous son capot.
Par exemple, si vous ajoutez des fichiers individuels à la zone de stockage, vous pouvez utiliser la commande suivante :
git add -p
L’option -p vous permet d’effectuer des modifications de manière interactive. Vous pouvez passer en revue les modifications apportées à chaque fichier, puis choisir ceux que vous souhaitez mettre en staging. Cela peut vous faire gagner beaucoup de temps et vous aider à éviter de mettre en staging une modification non souhaitée.
Vous savez peut-être que vous pouvez mettre en staging des fichiers individuels, mais vous pouvez également spécifier un répertoire. Par exemple, pour mettre en staging tous les fichiers du répertoire « new-feature » :
git add new-feature
Il se peut que vous souhaitiez voir le résultat d’un site git add sans exécuter le processus dans son intégralité. Vous disposez d’une option pour cela :
git add --dry-run
git add -n
Lorsque vous exécutez cette commande, Git vous indiquera s’il ajoutera ou ignorera les fichiers. En parlant de fichiers ignorés, vous pouvez également les ajouter à la zone de staging si vous le souhaitez :
git add --force
git add -f
L’ajout de fichiers à la zone de staging peut être plus complexe qu’un simple scénario binaire « Ajouter ou ne pas ajouter ». Ainsi, l’une des commandes les plus importantes de Git peut couvrir une myriade d’éventualités.
Résumé
Une fois que vous avez les commandes de base de Git dans votre poche, vous avez 80 % de ce dont vous avez besoin pour effectuer les tâches régulières de contrôle de version de votre projet. Cependant, c’est dans les 20 % restants que les commandes avancées de Git peuvent briller.
Des commandes et des techniques telles que le rebasing, la bissection, la restauration de fichiers et bien d’autres encore vous permettront de vous sortir rapidement d’un mauvais pas. De plus, vous pouvez offrir une plus grande valeur à votre équipe et à votre projet, et vous pouvez aider à rationaliser les flux de travail, à augmenter la productivité et à avoir un effet global plus important en tant que développeur.
L’une de ces commandes Git avancées fera-t-elle partie de votre travail quotidien ? Faites-nous en part dans la section des commentaires ci-dessous !
Laisser un commentaire