Les commandes Git : De bonnes bases (1/3)

Maintenant, nous avons vu comment migrer votre projet sur git et adapter votre workflow de développement pour git. L’objectif est de progresser dans l’utilisation des commandes Git. Pour cela, je vais proposer une série de 3 articles (en un seul c’était totalement indigeste).

Dans cette série d’articles, j’essayerai de suivre le schéma suivant pour chaque description de commande ou use case :

  • Un exemple de contexte d’utilisation
  • La ou les lignes de commandes à exécuter
  • Si cela me semble nécessaire, quelques explications

Pour commencer,  si j’avais un conseil à donner c’est d’utiliser uniquement la ligne de commande. Cela vous permettra de progresser rapidement, après quelques semaines vous ne la quitterez plus.

Vous pouvez retrouver les articles suivants ici :

En savoir plus sur une commande

Je vais présenter uniquement des exemples basiques des commandes utilisées, mais ces dernières sont très riches, et possède des fonctionnalités que je n’ai moi même pas encore exploré.

git help nom_commande
git nom_commande --help

Je recommande la documentation de git en ligne, très bien faites et disponible en français.

Récupérer un dépôt via le système

Quand on commence avec Git, la première étape est généralement de récupérer un projet depuis un dépôt distant (github, bitbucket, le serveur git de votre entreprise …). Pour cela deux possibilités:

# mettre le contenu du dépôt dans le répertoire courant, ce dernier doit être vide.
git clone <URL_DEPOT> .
# ou mettre le dépôt dans un répertoire créé automatiquement au nom du projet
git clone <URL_DEPOT>

Le point dans la première commande peut être remplacé par un chemin de votre système de fichier.

Mettre à jour le dépôt local

S’il y a eu des modifications partagées par d’autres développeurs à récupérer il faut utiliser la commande « pull ».

git pull

Le pull est l’équivalent de « git fetch », qui rapatrie les commits depuis le dépôt central, et « git merge » qui récupère et fusionne les modifications des fichiers. Si vous avez des modifications en cours, il est possible que des conflits apparaissent.

Vérifier l’état de votre dépôt en local

A n’importe quel moment, il est possible de vérifier l’état de git en local. La commande « status » permet de savoir où l’on en est, quels sont les fichiers ajoutés, modifiés,  indexés ou en conflit etc …

git status

Voici un exemple de git status  :

Résultat d'un git status

On obtient les informations suivantes :

  • Le dépôt local est actuellement sur la branche « develop » et a un commit d’avance sur la branche du dépôt distant
  • Le fichier NumberScientificNotation.java est un nouveau fichier indéxé
  • Les fichiers BlindConstants.java et BlindStruncture.java sont deux fichiers modifiés non ajouté à l’index dans leur nouvelle version
  • Les fichiers .tern-project et NumberScientificNotationTest.java sont des nouveaux fichiers pas encore indéxé

Placer de nouveaux fichiers à l’index ou ré-indexer un fichier modifié

La commande « add » permet d’ajouter des fichiers dans l’index. Que ce soit des fichiers nouvellement ajoutés au projet ou des fichiers modifiés par le développeur. Dans les deux cas, la même commande est utilisée.

git add FileName
# la commande add de git accepte les patterns, quelques exemples
git add .
git add *
git add src/*

Cette commande est indispensable au processus de versionning. Les fichiers doivent être ajoutés à l’index pour être ensuite versionné.

Enlever un fichier de l’index

En utilisant des patterns pour ajouter des fichiers dans l’index, il est possible d’y ajouter des fichiers par erreur, on peut les retirer grâce a la commande « reset ».

git reset chemin/du/fichier

Supprimer, déplacer ou renommer un fichier dans l’index

Si on souhaite supprimer un fichier présent dans l’index (nouvellement ajouté ou déjà commité), il faut utiliser la commande « git rm ».

# pour un fichier
git rm filename
# pour un dossier
git rm -r folderName

Cette commande indique à Git la suppression du fichier et le supprime du système.

Pour renommer ou déplacer un fichier indexé il faut utiliser la commande « git mv »:

git mv ancien/chemin nouveau/chemin
git mv ancien_nom nouveau_nom

Annuler les modifications d’un fichier

Si un fichier a été modifié à tord, il est possible de récupérer sa dernière version commité :

git checkout -- votreFichier
# cette commande cette les pattern
git checkout -- src/java/test/*

Commit des modifications

Après avoir réalisé des modifications et les avoir indexés via la commande « git add », il faut les commiter pour les intégrer au versionning.

git commit -m "Le message de votre commit"

Ces changements ne sont pas partagé sur le dépôt centrale, ce versionning est local. De plus, le message est très important pour l’historique du projet, je conseil de le renseigner proprement en décrivant ce qui a été fait et mettre le numéro des fiches traitées.

En cas d’erreur sur le message ou la liste de fichier à commiter de votre dernier commit, il est possible de revenir sur ce commit avec :

git commit --amend
# si vous souhaitez modifier uniquement le message 
git commit --amend -m "Mon nouveau message"

Envoyer les commits sur le dépôt distant

Après avoir fait les modifications souhaitées, les avoir ajoutées à l’index et versionnées. Pour les partager, il faut envoyer les modifications sur le dépôt grâce à la commande « push ».

# sur le master courante
git push 
# sur une branche spécifique
git push origin <branchName>

En conclusion

Ce premier article a décrit un ensemble de fonctionnalités qui permettent de récupérer un projet, le modifier et partager nos modifications. Grâce à ces dernières, il est possible de travailler seul ou avec une très petite équipe. Cependant, les commandes expliquées ne permettent pas de participer à des projets avec des équipes nombreuses possédant souvent un workflow de développement plus complexe à base de branches.

Le second article abordera certaines commandes permettant d’intégrer des workflows plus complexe. J’espère pouvoir sortir la suite très rapidement. Cet article contiendra la gestion de branche, des tags et quelques informations sur le merge et le rebase. Le dernier article traitera de commande un peu plus poussé ( comme bisect) et de quelques configurations de git.

N’hésitez pas à laisser un commentaire si vous avez des questions ou si vous avez d’autres exemples intéressants.

Sources :


Partager l'article :

Facebooktwittergoogle_plusredditlinkedinmail
 

4 commentaires

  1. Florian Guillot Répondre

    Super ! J’espère voir la suite très vite. Je n’ai jamais vu d’article sur GIT aussi compréhensible.
    Dans ma boite, nous avons trois parties sur git, là où tu en à deux : master, develop, et toutes nos branches de travail. Notre develop à nous serait ta master à toi, et notre master devient alors encore plus « clean ».
    Comme tu dis vouloir augmenter tes compétences éditoriales, attention à la phrase qui propose de laisser un commentaire 😉
    Bonne continuation.

    • Wodric Auteur de l’articleRépondre

      Hello,

      De rien, tu trouves les articles suivants en début d’article si tu souhaites en découvrir un peu plus 🙂

Vous aussi participez, laissez un commentaire