Git a été créé par Linus Torvald et est distribué sous licence GNU GPLv2. C’est un outil libre et open source de gestion de versions, adapté aux projets de toutes tailles. Il a l’avantage d’être facile à installer, à maîtriser et est multiplate-forme (Windows, Mac, Linux).
Avant de poursuivre, je tiens à préciser l’objectif de cet article et mes intentions. Je suis, peut-être comme vous, un utilisateur avec ses propres outils et manies, à cause de contraintes de travail ou d’habitudes. Mes façons de faire ne sont sûrement pas optimales, mais elles fonctionnent pour moi, elles me conviennent et m’ont permis d’améliorer et de sécuriser certains aspects de mon travail. Aussi, j’utilise Git avec Bitbucket car ce dernier permet de conserver ses dépôts privés et ce, gratuitement.
J’espère que cet article et ces astuces vous seront utiles. Si vous n’y comprenez rien, vous pouvez apprendre l’utilisation de Git via OpenClassrooms, dont un lien direct est indiqué au bas de cet article. Vous pouvez aussi poser vos questions dans les commentaires.
Installation…
En quelques clics, à partir du site de Git, telechargez l’éxecutable pour Windows et installez-le. Pendant l’installation, profitez-en pour créer votre compte Bitbucket si ce n’est déjà fait.
Au commencement fût git init
En local, sur votre machine, créez un nouveau dossier, ouvrez-le, cliquez droit en maintenant la touche shift (⇧) de votre clavier puis « Ouvrir une fenêtre de commande ici ».
Dans cette console, tapez git --version
, par exemple, pour vérifier que Git est bien installé et fonctionnel. Si cette commande vous retourne une erreur, il ne vous reste plus qu’à vérifier son installation.
Avant toute chose, il faut configurer votre identité. C’est utile entre autres afin de retracer les modifications de chacun à partir de l’historique. Tapez dans la console : git config --global user.name "Prénom et nom ou pseudo"
, puis git config --global user.email "votre.adresse@email.ext"
en prenant soin d’indiquer la même adresse e-mail que celle de votre compte Bitbucket.
À tout moment, utilisez la commande git config --list
pour afficher la configuration de Git.
Vous pouvez désormais initialiser votre dépôt, tout simplement en tapant git init
. Vous remarquerez qu’un dossier « .git » a été créé.
Pour aller plus loin : git config, git init.
Premier voyage
Créez un fichier (readme.md par exemple) et lancez la commande git status
.
Vous remarquerez les indications suivantes :
- On branch master : vous êtes positionné sur la branche « master » ;
- Initial commit : le prochain commit sera le premier de cette branche ; (à vérifier)
- Untracked files : liste des fichiers modifiés mais non suivis par Git.
Afin d’ajouter readme.md à la liste des fichiers suivis, tapez git add readme.md
. Si vous avez plusieurs nouveaux fichiers et afin de tous les ajouter en une fois, utilisez le joker (un point) ce qui donne git add .
.
Tapez git status
pour observer le changement : le fichier est maintenant dans la liste sous la rubrique « Changes to be commited« . Remarquez la mention « new file » précédant le nom de votre fichier. Il indique son statut dans le suivi. Cette mention peut être « modified » ou « deleted« .
Vous êtes maintenant prêt pour créer votre premier commit. Pour ce faire, tapez git commit -am "Initial commit"
. Il faut comprendre ici que vous ajoutez à votre commit les modifications des fichiers suivis (-a) et un message (-m) « Initial commit » qui, dans vos commits suivants, devra être plus explicite afin de vous aider à vous repérer plus facilement dans l’historique.
Pour aller plus loin : git status, git add, git commit.
Retour vers le futur
Si nous conservons le parallèle au voyage dans le temps, l’historique permet de remonter le temps, les branches de changer de ligne temporelle et la console est la machine à voyager.
Il existe 3 moyens immédiats utiles pour lire l’historique de vos modifications :
- À partir de la console de Windows ou du Git Bash, en tapant
git log
; - Git History via une interface assez simple mais moche, disponible en cliquant droit dans votre dépôt ;
- Lorsque le remote est configuré, par celui-ci.
Si vous souhaitez parcourir la liste des outils avec une interface, compatibles ou conçus pour Git, je vous invite à visiter la page Interfaces, frontends and tools du Wiki de Git.
Vous aurez accès aux informations suivantes : une chaîne de 40 caractères (ID), l’auteur du commit et la date et l’heure auxquelles le commit a été enregistré et le message qui lui a été assigné.
L’information importante et utile afin de revenir en arrière, c’est l’identifiant du commit. Après l’avoir obtenu, pour vous rendre à cette position de l’historique, tapez dans la console git checkout abc1234
en sachant que abc1234 doit être remplacé par l’ID du commit (ou ses 7 premiers caractères) dont il est question : un message vous indiquera que vous vous situez maintenant à l’emplacement abc1234 de votre historique.
Lorsque vous souhaiterez retourner à votre position initiale, votre branche principale, il vous suffira de taper git checkout master
.
Pour aller plus loin : git log, git checkout.
Lignes temporelles
Utilisez les branches pour effectuer des modifications sur votre dépôt sans que la branche principale « master » ne soit modifiée. Vous bénéficiez ainsi du suivi des modifications et vous pouvez retourner à la branche principale sans problème et ce à n’importe quel moment. Ensuite, lorsque vous avez terminé sur votre nouvelle branche, une simple commande vous permet de la fusionner à la branche principale.
À partir de votre dépôt, tapez git checkout -b nom-de-branche
pour créer une nouvelle branche et vous y positionner. Toutes les modifications suivantes ne seront effectives que sur cette branche, la branche « master » restant intacte.
Afin de connaître les branches existantes et savoir sur laquelle vous êtes positionné, tapez git branch
. Pour changer de branche, ou pour revenir à « master » tapez git checkout nom-de-branche
, comme pour naviguer dans l’historique.
Lorsque vous souhaitez reporter vos modifications sur la branche « master », les fusionner, positionnez-vous sur celle-ci en tapant git checkout master
puis utilisez la fonction merge : git merge nom-de-branche
. Si vous n’avez plus besoin de cette nouvelle branche, supprimez-la sur votre dépôt local en tapant git branch -D nom-de-branche
et/ou sur votre dépôt distant en utilisant la commande git push origin --delete nom-de-branche
.
Pour aller plus loin : git branch, git checkout, git merge.
Vers l’infini et au delà
Le dépôt distant (remote) vous sera très utile, même si vous travaillez seul. Il vous permet entre autres de pouvoir bénéficier d’une sauvegarde dans un lieu sûr, en ligne, mais aussi de pouvoir travailler sur plusieurs postes de travail ou en collaboration avec d’autres personnes.
Tout d’abord, il faut créer ce dépôt en ligne. Connectez-vous à Bitbucket et cliquez sur « Créer > Créer un dépôt ». Sélectionner le type de dépôt « Git », cochez « Gestion de bug » et « Wiki » si vous souhaitez en bénéficier (vous pouvez les activer/désactiver plus tard si besoin) et cliquez sur le bouton « Créer le dépôt ».
Ensuite, il faut indiquer à votre dépôt local l’origine de votre dépôt distant, en tapant git remote add origin https://anthony-d@bitbucket.org/anthony-d/test.git
en remplaçant bien sûr par votre propre URL, que vous trouverez à partir de la page de votre dépôt sur Bitbucket, en cliquant sur le lien « Cloner » puis en sélectionnant HTTPS. Tapez git push -u origin --all
pour modifier votre dépôt distant afin qu’il corresponde à votre dépôt local.
Si vous vous êtes trompé dans l’URL, pas de panique, il vous suffit de taper git remote set-url origin http://nouvelle-url
.
Il y a deux commandes a bien connaître qui sont git push origin master
pour la synchronisation de votre dépôt local vers celui distant, et git pull origin master
du distant vers le local. À chaque fois, le mot de passe de votre compte Bitbucket vous sera demandé, sauf si vous avez configuré le SSH pour Git (attention dans ce cas, l’URL de remote origin sera différente).
Notez qu’il est très important d’être le plus à jour possible de votre dépôt distant en synchronisant dans les deux sens, surtout lorsque vous travaillez à plusieurs.
Astuce : si vous souhaitez synchroniser les branches que vous avez créé en local, il suffit de remplacer « master », dans la commande, par le nom de votre branche.
Pour aller plus loin : git remote, git push, git pull.
Guerre des clones
Parfois, vous aurez besoin de créer un dépôt local à partir d’un distant ou tout simplement copier un dépôt pour le tester ou proposer des modifications. Pour ce faire, il faut le cloner à l’aide de la commande git clone https://anthony-d@bitbucket.org/anthony-d/test.git
. Notez que dans cet exemple cela créera un dossier du nom du dépôt (../test.git donc /test). Pour cloner le dépôt dans le dossier courrant, utilisez la commande git clone https://anthony-d@bitbucket.org/anthony-d/test.git .
(ajoutez un point à la fin pour indiquer « ici »).
Pour aller plus loin : git clone.
.gitignore
Dans la plupart de vos projets, en fonction de leur configuration (PHPStorm, SublimeText, …) ou de leurs caractéristiques (Vagrant, Sass, Symfony, …), vous aurez besoin ou envie de ne pas suivre les modifications de certains fichiers afin de conserver un dépôt propre. C’est là qu’entre en scène le fichier .gitignore, dans lequel vous listerez tous les fichiers et dossiers à exclure du suivi des modifications.
Pour vous faciliter la tâche, il existe sur le web une multitude de templates à utiliser afin de garnir ce fichier. gitignore.io semble l’outil idéal, mais si vous le préférez, vous pouvez jeter un œil au dépôt github/gitignore.
Pour aller plus loin : gitignore.
Le jeux des différences
Vous n’en aurez peut être jamais besoin, moi-même je ne l’utilise plus beaucoup. Cela me permettait de vérifier si le contenu des patchs que j’envoyais à mes clients, pour les déposer en production, était complet en comparant la liste des fichiers à cette liste. Pour connaître ces différences, tapez git diff --name-status master..nom-de-branche
.
Astuce : en ajoutant > nom-de-fichier.txt
à la fin de vos commandes, vous exporterez la réponse de votre commande dans un fichier.
Pour aller plus loin : git diff.
Excursions temporelles
Pour la petite histoire, j’ai un rôle de développeur-intégrateur sur un projet d’un de mes clients. Afin de sécuriser les mises en production, nous travaillons sur 3 environnements séparés (développement, industrialisation et production). Je n’ai accès qu’à l’environnement de développement, et mon client aux deux autres.
Avant d’utiliser Git, je répertoriai dans un tableau sur Google Drive chaque fichier modifié, sa date de dernière modification (pour vérifier au moment de copier les fichiers) et des commentaires afin de conserver un historique des modifications facile à comprendre. Je regroupai ces fichiers dans des patchs, que je livrais à mon client pour qu’il puisse l’installer en industrialisation, vérifier l’intégrité des modifications puis les publier en production.
Tout ça me prenait un temps monstre, ce qui était en plus stressant si j’avais oublié de reporter une modification dans ma liste…
Depuis Git, j’organise ces patchs en branches, ce qui me permet de conserver la branche « master » intacte et identique aux environnements d’industrialisation et de production. Je fusionne ces branches-patchs dès que les modifications sont envoyées sur ces deux environnements. Et en plus, j’ai trouvé une ligne de commande qui m’est utile afin de regrouper tous les fichiers modifiés, en un claquement de doigt :
[shell]for /f "usebackq tokens=*" %A in (`git diff-tree -r –no-commit-id –name-only –diff-filter=ACMRT master..nom-de-branche`) do echo FA|xcopy "%~fA" "C:\TEMP\chemin-du-dossier\%A"[/shell]
Cette commande dépose dans un dossier « C:\TEMP\chemin-du-dossier » les fichiers modifiés dans la branche « nom-de-branche » en comparaison avec la branche « master ». Couplée avec la commande git diff --name-status master..nom-de-branche > nom-de-fichier.txt
je peux savoir facilement, si nécessaire, quels fichiers supprimés je dois signaler à mon client.
Exit
Comme indiqué au début, si vous n’avez rien compris à tout cela mais que vous souhaitez quand même apprendre à utiliser Git, faites comme moi : suivez le cours de Marc G. Gauthier sur OpenClassrooms. Il est vraiment bien fait.
Plus récemment, Codecademy a lancé un nouveau cours sur Git, mais qui n’est pas encore complet : Learn Git.
Pour ma part, je ne peux plus me passer de Git pour mes projets web. Il m’offre la flexibilité et la sécurité dont j’ai besoin. Il me permet d’être plus efficace et réactif.
Photo : Time paradox, par Stéfan | Flickr | BY-NC-SA