Git : Les commandes de base

• Dev
• Git
• Tuto

Avant toutes choses :

Cela fait un moment que je n’ai pas écrit d’article. J’étais pleins de bonnes résolutions (comme d’hab’ quoi), mais la charge de travail, le Covid (saloperie va) et un changement de taf et de logement avec la construction de ma maison on fait que j’ai un peu délaissé ce blog. L’article que vous allez lire est en brouillon depuis 2 ans !! Autant dire qu’il a eu le temps de bien se reposer ^^ Bref j’ai fais un p’tit coup de ménage et je le poste tout de même :) Bonne lecture !

P.S : Putain ca fait plaisir de vous revoir :P

Salut les amis !

Bon ce n’est pas parce qu’on parle de code ici qu’on ne doit pas connaitre les bases du travail collaboratif avec git. Mon but ne sera pas de vous faire un cours sur git avec création d’un repo car la doc est assez bien foutu pour ça. Mais cet article est plus là pour vous donner les billes pour « pousser » ou « récupérer » vos modifications et ainsi sécuriser votre travail en cas de crash de disque dur ou tout simple pour bosser avec d’autres personnes.

Déjà pourquoi connaitre ces commandes de base Git ?

Il est important de comprendre ce que l’on fait. Vous pourriez très bien utiliser votre IDE et cliquer sur les boutons à disposition. Après tout, tout est là pour ça et pour vous simplifier la tâche. Mais perso, même si j’utilise PHPStorm au quotidien, je préfère encore faire manuellement dans mon terminal mes push, rebase, commit, etc. Et je pense sincèrement qu’il est important de savoir ce qu’il y a derrière une action et pourquoi on l’utilise.

Commençons !

Je pars du principe que vous avez initialisé votre repository (repo pour les intimes) dans votre projet.

A noter : on lance une commande git toujours en mettant git en premier.

Voici donc quelques commandes non exhaustives qui pourront vous servir. Je vais sûrement en oublier, donc ne criez pas au scandale s’il en manque mais le but est juste de donner des premières commandes et de ne pas réécrire la documentation ;) :

• git status : Avec cette commande vous allez voir le statut de tout ce qui est en cours de modifications en local et qui n’a pas été push sur votre repo. (nous verrons plus bas ce que c’est que le terme push). Exemple : 
  
• git add : Alors là, je ne vais pas réexpliquer car j’ai écris un article assez détailler sur le sujet par ici :)
  
  
• git commit : Cela vous permet de valider les modifications et de les réserver dans un coin. Attention à ce stade vous n’avez toujours rien envoyé sur le repo. A noter que vous pouvez ajouter des paramètres et faire un git commit -m « mon message » mais je ne vous conseille pas de faire ceci. Avec un simple commit vous serez plus à l’aise pour saisir un chouette commit bien structuré ;) On y reviendra plus tard.
  Vous pouvez également cumuler plusieurs git commit si besoin. Toutefois, éviter de faire plusieurs git commit juste pour une faute d’orthographe par exemple. Essayez d’être structuré dans vos actions :) Au pire, utiliser un rebase pour merger vos commits.
  
  
• git push : push va permettre de « pousser » (push = pousser vers votre repo) vos modifications sur votre repo. Plus exactement, cela va pousser les modifications sur la branche distance équivalente à la votre en local sur le repo. C’est à ce moment-là que votre git commit va être envoyé.
  A noter qu’à la création d’une branche, le premier push que vous ferez risque de râler un peu :P Sur le premier push au lieu d’un simple git push vous devrez faire git push –set-upstream origin fix/ma-branche2 (ou git push -u origin fix/ma-branche2 pour la version raccourcie). En gros pour schématiser un peu, un push va chercher sa référence sur le « catalogue » distant pour lui envoyer ses modifications. S’il ne le trouve pas, il vous insultera ^^ Donc, le -u va permettre de créer une référence dans le catalogue distant, puis pousser ses modifications
  
  

• git pull : pull va permettre de « récupérer » (pull = tirer vers soit, ramener du repo vers notre local) les dernières modifications qui sont sur votre repo. En général, on utilise cela quand vos collègues ont mergés leurs branches et que vous voulez mettre à jour votre local pour récupérer leur taf.

• git checkout feat/ma-branche : vous permet de basculer sur une autre branche (en l’occurrence, ma-branche dans notre exemple et se situe dans feat)
• git checkout -b fix/ma-branche2 : vous permet de créer une nouvelle branche grâce au paramètre -b et de basculer dessus. Dans notre exemple nous venons de créer une branche ma-branche2 dans fix et nous avons basculé dessus automatiquement.
  
  
• git log : vous permet de voir les logs de tous les push que vous et vos collègues ont fait sur la branche
  
  
• git fetch : vous permet de mettre à jour les infos sur la branche distante sur laquelle vous travaillez. En gros voyez ça comme une mise à jour du catalogue que vous avez en local. Pour schématiser, le fetch va interroger votre repo, récupérer la liste des branches disponibles et leurs états et mettre à jour votre « catalogue » local. Attention fetch ne remplace pas pull. A noter que pull fait les 2 : il fait d’abord un fetch et ensuite il met à jour la branche en local.
  Astuce : Ajoutez le paramètre –all (git fetch –all ou git fetch -a dans sa version raccourcie) pour mettre à jour son « catalogue » local de toutes les branches distantes disponibles.
  
  
• git branch –list : Cela va vous lister toutes les branches que vous avez en locale. Et c’est aussi à ce moment-là que vous ferez un arrêt cardiaque en vous rendant compte du merdier que vous avez accumulé. C’est là qu’une voix dans votre tête ressemblant à celle de votre mère vous dira : « Mais tu vas la ranger ta chambre !!? C’est le bordel ici !! ».
  Ne vous inquiétez pas, j’ai la solution : git branch -d feat/ma-branche. Et parfois, pour une raison que je n’ai pas trouvé, vous ne pourrez pas supprimer une branche. Remplacer -d par -D qui est l’équivalent d’un -d –force.
  Astuces : Vous pouvez très bien supprimer plusieurs branches d’un coup : git branch -d feat/ma-branche fix/ma-branche2.

Petit bonus :

Ecrire (selon moi bien entendu) un bon commit :

Ce que je vais vous présenter ici est, selon moi, une bonne façon d’écrire un commit. Attention cela dépendra aussi de votre entreprise et de ses besoins/méthodes de travail. Donc cela n’engage que moi mais libre à vous de faire votre propre rédaction de commit. Le plus important est que cela soit lisible et que tous vos commits soient homogènes entre collègue.

Une fois le git commit fait, voici une structure propre pour vos commits :

feat(header): champ recherche
Ajout d'un champ de recherche dans mon header

fix(header): champ recherche
Correction de mon champ de recherche dans mon header

Vocabulaire :

• feat = feature = nouveauté
• fix = correction

Voilà vous avez une première base avec des commandes de bases pour faire du git pour vos projets. Je n’ai pas tout aborder, comme le rebase mais vous pourrez trouver plus d’information sur cet article que j’avais écris ici :) 

Bon git !

Longue vie et prospérité !