Comment git est-il généralement utilisé? Une paire de commandes de base pour « synchroniser tout le monde ». La frustration de git survient souvent chez ceux qui ne dépassent jamais cette compréhension superficielle. Cependant, la maîtrise de git sera certainement payante. Combien de temps passez-vous à utiliser git? Je dirais qu'à votre ceinture, il y a beaucoup d'outils que vous utilisez moitié moins souvent et que vous passez deux fois plus de temps à étudier.



Si vous voulez en savoir plus sur git, je vous suggère de commencer par le chapitre 10 de Pro Git (c'est gratuit!), Puis les chapitres 2, 3 et 7. Le reste est facultatif. Dans cet article, nous verrons comment utiliser les outils décrits dans le livre pour un travail discipliné et productif dans git.

Les bases: de bonnes descriptions de commit

Vous avez peut-être déjà entendu cela, mais soyez patient. En général, vous n'avez pas besoin d'utiliser git commit -m " " . Commencez par configurer git pour utiliser votre éditeur préféré: git config --global core.editor vim , puis lancez simplement git commit . L'éditeur s'ouvrira et vous pourrez y écrire votre description du commit. La première ligne doit être limitée à 50 caractères et complétée par une phrase: après avoir appliqué ce commit ... "corrigera le rendu du texte dans les langues CJK", "ajoutera la prise en charge du protocole v3", "remodèlera le traitement CRTC", etc. Ensuite, ajoutez une ligne vide et passez à la description détaillée de la validation , qui doit être codée en dur dans 72 colonnes et inclure des détails tels que la justification de la validation, les compromis, les restrictions d'approche, etc.

Nous utilisons 72 caractères car il s'agit de la largeur standard d'un e-mail , et l'e-mail est un outil important pour git. Une limite de 50 caractères est utilisée car la première ligne devient l'objet de votre e-mail et vous pouvez ajouter beaucoup de texte comme “[PATCH linux-usb v2 0/13]” . Vous pouvez trouver ces restrictions de formatage ennuyeuses et contraignantes, mais gardez à l'esprit que d'autres lisent les journaux dans un contexte différent de vous. Je lis souvent les journaux de validation sur un moniteur vertical, et il ne compressera pas autant de texte sur une seule ligne que votre écran 4K 16: 9.

Chaque commit doit être un changement autonome

Chaque commit ne doit contenir qu'un seul changement - évitez les petits changements non liés dans un commit (à cet égard, je pourrais plus souvent écouter mes propres astuces). Évitez également de diviser un changement en plusieurs validations, à moins que l'idée ne soit divisée en étapes distinctes, chacune représentant un changement complet. S'il y a plusieurs changements dans votre arborescence de travail et que vous ne devez en valider que quelques-uns, essayez git add -i ou git add -p . De plus, chaque commit doit être compilé, réussir tous les tests et éviter les bugs connus qui seront corrigés dans les futurs commit.

Vous pouvez maintenant prendre n'importe quel commit et vous attendre à ce que le code fonctionne correctement. Cela vous sera utile plus tard, par exemple, lors de l'inclusion sélective des validations dans la branche de publication. Cette approche améliore également l'utilité de git-bissect ¹ , car si vous vous attendez à ce que le code compile et réussisse les tests pour chaque validation, vous pouvez passer un script git-bisect qui vérifie par programme l'arborescence pour éviter les erreurs et évitera les faux positifs. Ces validations autonomes et bien décrites simplifieront la préparation des descriptions de versions à l'aide de git-shortlog , comme Linux le fait avec les versions Linux .

C'est difficile de bien faire les choses la première fois

Nous arrivons à l'une des fonctionnalités les plus importantes de git, qui la distingue de ses prédécesseurs: l'édition d'histoire. Tous les systèmes de contrôle de version sont livrés avec une sorte de "machine à remonter le temps", mais avant, ils étaient pour la plupart en lecture seule. Cependant, la machine à remonter le temps est différente: vous pouvez changer le passé. En fait, vous êtes même encouragé à le faire! Mais je vous préviens: ne changez que le passé, qui n'est pas encore entré dans une branche publique stable.

La conclusion est la suivante. Écrire des commits sans erreurs, des commits autonomes avec une bonne description est difficile du premier coup. La modification d'une histoire, en revanche, est facile et fait partie d'un workflow git efficace. Découvrez git-rebase et utilisez-le librement. Vous pouvez utiliser le rebase pour réorganiser, fusionner, supprimer, modifier et fractionner les validations. Par exemple, j'apporte généralement des modifications au fichier, soumets un commit de correction ( git commit -m fixup ), puis j'utilise git rebase -i pour le fusionner dans un commit précédent.

Divers conseils

• Lisez le mana! Sélectionnez une page de manuel git aléatoire et lisez-la maintenant. De plus, si vous n'avez pas lu la page de manuel git de niveau supérieur (juste man git ), faites-le.
  
• Au bas de chaque mana pour une commande git de haut niveau se trouve généralement une liste de commandes git de bas niveau sur lesquelles la commande de haut niveau s'appuie. Si vous souhaitez en savoir plus sur le fonctionnement de la commande git de haut niveau, essayez de lire ces pages de manuel.
  
• Apprenez à sélectionner les bons commits avec la sélection de rev .
  
• Les branches sont utiles, mais vous devez apprendre à travailler sans elles et avoir également un bon ensemble d'outils à votre ceinture. Utilisez des commandes comme git pull --rebase , git send-email -1 HEAD~2 et git push origin HEAD~2:master .

1. En résumé, git bisect est un outil qui effectue une recherche binaire entre deux commits dans votre historique, en regardant les commits entre eux un par un afin que vous puissiez vérifier une erreur. De cette façon, vous pouvez calculer le commit à l'origine du problème. ↑