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 :
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 :
- Manuel de référence : https://git-scm.com/book/fr/v1





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.
Merci pour ton retour, ça fait plaisir 🙂 . J’espère que les prochains articles seront aussi limpide pour toi. Le workflow de ton entreprise ressemble au git flow (http://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html) que je cite dans d’autres articles sur git.
J’avoue que j’ai oublié la petite phrase pour les commentaires. Je rajoute ça !
Merci beaucoup pour ce article tres bien detaillé, je te tire mon chapeau. J’attends la suite avec impatience.
Hello,
De rien, tu trouves les articles suivants en début d’article si tu souhaites en découvrir un peu plus 🙂