Les commandes basiques de GIT

Un projet à gérer

Avant de s’occuper des commandes GIT, il nous faut un projet à gérer. Pas besoin de faire un énorme dossier avec plusieurs sous-dossiers, vous pouvez même gérer les versions d’un simple fichier texte. Mais faisons comme si on avait un projet web. PS: Je pars du principe que vous êtes sur windows mais je sais que ce n'est pas le cas pour certains. Je m'en excuse d'avance.

Maintenant, il est temps de jouer avec GIT. Comme partout, il faut d’abord s’identifier car si on s’amuse à faire des commit sans dire qui on est, ça risque de poser problème pour savoir qui a fait quoi. Pas besoin de mettre son âge ou sa taille, son nom et son email suffiront. En ligne de commande, voici les deux choses à taper :

git config --global user.name "Ryan" 

git config --global user.email "Ryan@hotmailetgmail.com"

Notez qu’il y a « global » dans les lignes de commandes. Ça veut tout simplement dire que ces identifiants fonctionneront pour en global sur votre ordinateur. Donc vous n’aurez plus besoin de faire ça si vous gérez un autre projet.

Initialisation de GIT

Maintenant, en étant dans le dossier visé, on créer une initialisation de GIT avec cette ligne de commande :

git init

Normalement, le message suivant s’affiche : Initialized empty Git repository in C:/… . Félicitations, GIT va maintenant tracer votre dossier. Mais comment fait-il ? C’est simple, un dossier caché a été créé dans le projet (.git) et c’est dans ce dossier que seront stockés les infos.

Laissez ce dossier tranquille. Si vous être débutant, ne vous amusez surtout pas à modifier les fichiers.

Voir les modifications

La commande GIT que vous utiliserez le plus au cours de votre vie, c’est cette commande :

git status

Cette commande magique vous permet de voir la statue de votre dossier GIT : Si des fichiers ont été modifiés, s’ils ont été commité ou pas, s’ils sont supprimés… Par exemple, si à ce stade je fais un « git status », j’obtiens ce message :

« On branch master » veut dire qu’on se trouve actuellement sur la branche master. « No commits yet » veut dire qu’on n’a encore pas de commit en attente. Ensuite, c’est là que ça devient intéressant, c’est la liste qui se trouve sous le « Untracked files ». On voit clairement la liste des dossiers en rouges, cela veut dire que GIT les voit, mais que pour l’instant ils ne sont pas encore tracés. Et c’est justement ce dont on va s’occuper juste après.

Ajout des dossiers

S’il te plait GIT, peux-tu tracer le dossier « components » ? Comme rien n’est magique, il va falloir le faire soi-même en ligne de commande :

git add component/

Même s’il ne nous affiche pas de message de confirmation, tout s’est bien déroulé. Mais pour en être sûr, n’oubliez pas cette commande très utile :

git status

Vous voyez que la ligne « component » et ce qu’elle contient (juste un fichier) est en vert. Le dossier est donc ajouté et n’attend plus qu’à être commit. Mais si au final on a décidé de mettre tous les dossiers, on peut toujours faire :

git add .

Le point signifie que tout ce qui n’est pas encore tracké par GIT le sera. Si on regarde maintenant notre console avec un « git status », nos lignes qui étaient en rouge passeront en vert. La suite, c’est de commit tout ça.

Commit

Nous allons donc sauvegarder tout ça dans un joli commit. Pour ça, il suffit simplement de taper cette commande :

git commit -m "mon premier commit"

« mon premier commit » est le nom du commit qu’on lui donnera. Je vous déconseille d’utiliser des phrases génériques du type « save ». Il faut être le plus précis possible pour ne pas être perdu en cas de problème. N’utilisez pas GIT pour juste sauvegarder vos travaux. Il existe d’autres outils pour ça.

Back to the past

Il est possible qu’après avoir fait votre commit, vous vouliez revenir en arrière et annuler ce même commit. Pas de soucis, la commande est très simple :

git reset --soft HEAD~1

Votre dernier commit a donc été annulé. Vous pouvez faire vos modifications avant de refaire un commit.

Dans le cloud

Si comme la plupart des gens, vous envoyez vos travaux sur un serveur externe, alors il va falloir le préciser à GIT. Imaginons que vous avez crée un repository sur le célèbre site Gitlab, normalement il devrait vous donner un lien qui ressemble à ça :

git remote add origin git@gitlab.com:lesitededjoher/djoher.git

Et c’est exactement cette commande qu’il faudra rentrer dans votre ligne de commande pour que GIT sache que vous avez un repository externe dans le cloud qui n’attend que vos travaux. La dernière chose à faire, c’est d’envoyer votre commit là-bas.

git push origin master

Cette commande envoie votre commit sur le site. Et si vous regardez bien, il envoie ça dans la branche « master ». Félicitation, vos travaux sont sur le cloud, mais il est temps maintenant de vous parler un peu des branches.

Les branches

Les branches vont vous permettre d’avoir un peu plus de sureté dans votre projet. Généralement, on n’envoie pas sur la branche « master » car elle doit être clean. Vous devriez avoir une branche qui porte le nom de votre feature (voire juste vote nom/prénom). La personne responsable du repository s’occupera de fusionner les branches quand il jugera bon de le faire.

Bref, nous sommes toujours sur la branche master mais on va y partir tout en créant une nouvelle branche. Pour ça, on va faire cette commande :

git branch my_new_banch

Votre nouvelle branch portera le nom de « my_new_branch ». Mais elle est seulement créée, on n’est pas encore dessus. Il faut bien faire attention à regarder sur quelle branche on se trouve. Pour ça, pas besoin de faire un « git status », il suffit juste d’avoir l’œil.

C’est bien tout ça, mais maintenant il faut changer de branche. Avant de bouger, voici une commande qui vous permet de voir la liste des branch que vous avez en local (et en remote, on y reviendra) sur votre projet :

git branch -a

Sur cette image, vous voyez que j’ai deux branches : master et my_new_branch. Vous voyez aussi que master est en vert, cela signifie que c’est sur cette branche qu’on est actuellement. Fini le suspense, voici maintenant la commande pour changer de branche :

git checkout my_new_branch

Non seulement on voit le message de confirmation qui nous dit qu’on a bien changé de branche, mais en plus on voit (my_new_branch) sur notre ligne. Félicitation, vous être enfin dans votre branche.

Attention, n’oubliez pas que vous avez crée une branche en local, donc seulement présente dans votre ordinateur. Tant que vous n’avez pas fait un push sur votre repository présent sur le site type github ou gitlab, elle sera juste sur votre ordinateur. Et c’est aussi le cas des branches qui sont sur le site mais pas sur votre ordinateur. Normalement, quand vous ferez la commande « git branch -a », vous devriez voir les branches présentes en local, mais aussi celle qui sont sur le site. Vous savez maintenant comment changer de branche donc vous pouvez aussi vous mettre dans une branche qui n’est pas encore présent en local dans votre ordinateur. Et quand c’est fait, il faut télécharger les fichiers pour que vous ayez les mêmes fichiers de la branche, que ce soit sur le site ou sur votre ordinateur. Pour ça :

git pull

Ce n’est que le début

Vous savez maintenant les bases de GIT mais je vous conseille non seulement de creuser un peu plus le sujet, mais aussi de vous entrainez encore et encore. Quand vous serez à l’aise avec les lignes de commandes et tout l’esprit derrière GIT, vous aurez eu un gain d’expérience non négligeable. Sur ce, je vous souhaite une « git pull bonne_journée ».