Nous publions une traduction de l' article que nous avons trouvé sur hackernoon.com. Son auteur, Thiago Miranda, explique comment rendre le travail avec Git plus pratique et efficace.
À propos de quelques commandes extrêmement utiles dans Git
Depuis un mois, je fais de la programmation par paires et j'ai créé plusieurs centaines de commits dans Git. Dans l'article, je vais partager le plus important de ce que j'ai appris pendant cette période: je vais parler de travailler avec l'histoire des commits, des techniques réussies et comment les implémenter en utilisant une douzaine d'équipes.1. Quelle est l'histoire de Git?
Un registre précis de toutes les validations contenant les modifications apportées aux fichiers. Vous pouvez y suivre des modifications spécifiques et l'heure à laquelle elles ont été apportées, ou comparer la version actuelle avec la précédente. Où voir l'histoire? Entrez la commande via Git Bash:git log --oneline
Si vous avez trop de validations, vous pouvez passer d'un commentaire à un autre à l'aide des touches fléchées ou des touches Page précédente / Page suivante - comme dans tout autre fichier. Pour quitter, appuyez sur la touche de raccourci (q).2. À propos des commentaires sur les commits
N'écrivez pas de commentaires dénués de sens, ils doivent être concis et ne nécessitant aucune explication. Leur tâche consiste à indiquer les modifications que vous avez apportées au code et ce qu'elles affectent.- Comment ne pas: "Fixed index.html"
- Comment: "Amélioration de la vitesse de la barre de navigation"
Voyons à quoi cela sert.Imaginez que vous travaillez sur un projet d'une telle ampleur que la plupart des spécialistes qui y travaillent ne savent même pas. Vous développez une nouvelle fonctionnalité, la testez sur votre équipement, et tout fonctionne bien.Mais après une poussée, tout cesse soudainement de fonctionner, et la première chose que vous vérifiez est les modifications apportées lors du développement de cette fonctionnalité. Dans le journal Git, vous trouverez de nombreuses validations avec des commentaires dans le style "fixe". Imaginez combien de temps vous avez à consacrer à trouver le bon!3. Faites toujours des commits
Valide, valide et valide à nouveau. Fin de la fonction - ajout d'une validation, amélioration du style d'un élément de bloc - ajout d'une validation et ainsi de suite. Idéalement, vous devriez envoyer un commit à chaque changement.Vous pensez peut-être: pourquoi y a-t-il tant de commits? La raison principale est que vos nouvelles fonctionnalités peuvent entrer en conflit avec le code de quelqu'un d'autre, mais si vous effectuez toujours de petites modifications, les trouver et les corriger sera plus facile. Cela vous fait gagner du temps en suivant des dizaines ou des centaines de lignes modifiées dans le même commit.4. Corrigez le dernier commentaire sur le commit
Et si, après avoir ajouté un petit commit à votre référentiel local, vous souhaitez corriger la faute de frappe ou faire un commentaire sur le commit plus en détail? Faire des changements est assez simple avec la commande:git commit -m “correct message” --amend
Remarque: si vous avez déjà commencé à vous engager dans un référentiel distant, cette commande est préférable de ne pas utiliser.Voir la documentation officielle pour plus de détails .5. Combinez les derniers X commits en un seul
Situation: en envoyant un commit à une nouvelle fonctionnalité, vous comprenez que vous avez besoin d'une petite modification de plus, apportez des modifications minimales et recommencez ... En conséquence, 5 validations sont à peu près la même chose. C'est arrivé? Ces commits sont supprimés de la vue générale de votre histoire dans Git, mais si vous le souhaitez, ils peuvent être facilement corrigés à l'aide de la commande:git reset HEAD~3
La commande HEAD ~ 3 annule 3 commits supérieurs, y compris le plus récent. Dans cet exemple, vos trois dernières validations seront supprimées du journal, mais les modifications du code resteront en place. Il est maintenant temps de voir quel code vous devez valider, pour cela nous entrons la commande:git stage --diff
Vous verrez que toutes les modifications apportées aux validations que vous avez supprimées de l'historique sont désormais indexées, vous pouvez donc les valider à nouveau, cette fois en une seule fois.Notez que HEAD fait généralement référence au dernier commit que vous avez ajouté. Si vous n'êtes pas sûr, consultez le journal Git. Si votre dernier commit a été gelé (pas le cas le plus courant), la commande HEAD ~ 1 effacera tous les commits de la branche gelée. Pour en savoir plus, consultez la documentation.6. Supprimer le dernier commit avec modifications
Soyez prudent, car cette méthode effacera tous les changements sans la possibilité de revenir en arrière. Il est généralement utilisé après avoir expérimenté avec du code si leur résultat ne répond pas aux attentes. Je vous recommande d'essayer d'abord dans le référentiel sandbox.git reset –-hard HEAD~1
Maintenant, votre dernier commit a été supprimé, ainsi que toutes les modifications pertinentes dans le code.7. Effacez votre historique de commit
La façon la plus efficace d'effacer l'historique de validation est d'utiliser la commande rebase. Attention: vous pouvez supprimer un commit en appuyant accidentellement sur la mauvaise touche. Exécutons donc rebase de manière interactive (indicateur -i) avec la commande:git rebase -i HEAD~5
Dès que vous le saisissez, vous verrez une liste des 5 derniers commits (HEAD ~ 5) à l'intérieur du terminal. Toutes les validations sont triées par date, c'est-à-dire que la première sera la plus récente (cette liste est ouverte à l'aide de Vim, l'éditeur de texte Git par défaut qui permet de modifier les fichiers texte à l'intérieur du terminal). Et voici une brève instruction avec plusieurs commandes utiles. Dans la plupart des cas, vous aurez besoin des commandes squash et reword.Le remplacement de la commande pick par la commande squash supprimera cette validation du journal et toutes les modifications du code seront regroupées avec la dernière validation mise en évidence par la commande pick.Si vous souhaitez ajuster le commentaire, vous pouvez remplacer la commande pick par la commande reword et réécrire le commentaire.Vous pouvez maintenant passer à la fenêtre suivante, où vous devez écrire un commentaire pour le groupe de commits que vous allez coller à l'aide de squash. Pour continuer, appuyez sur ESC et entrez::wq!
Un deux-points est (:)nécessaire pour indiquer que vous voulez transférer la commande, (w)écrire (enregistrer) les modifications, (q)quitter et (!)exécuter la commande.Veuillez noter que chaque groupe de validation recevra votre commentaire. Le résultat peut être vérifié dans le journal Git.Si pour une raison quelconque vous quittez cette fenêtre sans terminer l'opération, vous pouvez revenir à tout moment avec la commande:git rebase --edit
Si vous souhaitez quitter la fenêtre sans enregistrer les modifications, appuyez sur la touche ESC et entrez::q!
Vim recevra une commande pour fermer le fichier sans l'enregistrer.8. Gérer l'indexation
Habituellement, vous devez envoyer des validations à un seul fichier ou à un groupe de fichiers associés. Mais alors comment faire rapidement des changements lors de l'indexation?Supposons que vous ayez 3 fichiers, et que seulement 2 d'entre eux doivent être validés. Dans ce cas, vous pouvez essayer la commande suivante:git add .
Supprimez maintenant le fichier dont vous n'avez pas besoin de l'indexation:git reset -- Readme.txt
Et vérifiez le résultat:git status
Ajoutez tous les fichiers d'une extension, par exemple CSS:git add *.css
Vous avez tout ajouté par erreur? Effacez ensuite l'index à l'aide de la commande:git reset --
Si vous avez besoin d'opérations plus complexes, vous pouvez ajouter des fichiers à l'index à l'aide du mode de dialogue:git add -i
Tout d'abord, sélectionnez une option en entrant le numéro approprié, par exemple (3), pour annuler vos actions.En sélectionnant une option, vous pouvez entrer une liste de fichiers que vous souhaitez supprimer de l'indexation, l'un après l'autre.Une fois terminé, appuyez sur (Entrée).Les fichiers sont ajoutés de la même manière. En utilisant l'option (4), ajoutez un fichier non suivi.Pour quitter, accédez au (q)menu des options.9. Conclusion
La principale chose à faire avant de passer à un référentiel distant, et surtout avant de fusionner votre branche, est de vous assurer de bien ranger l'historique des validations. Une fois que vous avez tout poussé dans un référentiel distant, rien ne peut être corrigé.Vous voulez en savoir plus sur la programmation par paires et commencer à distance? Consultez Microverse.org .