Débuter avec Git partie 2 : premier ajout de code

Après le premier article de cette série sur comment débuter avec Git, nous détaillerons aujourd’hui comment ajouter pour la première fois du code dans un dépôt de code source et les notions fondamentales de Git qui accompagnent ces opérations.

État initial du dépôt

Dans un premier temps, nous allons nous positionner dans le dépôt que nous avons créé au premier article sur notre poste de travail local et vérifier l’état courant de notre dépôt :

$ cd ~/toto
$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Plusieurs notions importantes dans le résultat de cette commande :

Le message On branch master vous signale la branche dans laquelle vous êtes positionné.
Mais qu’est-ce qu’une branche ? Retenons ici essentiellement que nous travaillons dans un état particulier du dépôt appelé branche et qu’il s’agit de celle par défaut, nommée master. Nous serons beaucoup plus précis sur cette notion dans un prochain article.
Le message No commits yet est assez explicite et indique qu’aucun commit n’a encore été enregistré dans le dépôt, ce qui est cohérent.
Mais qu’est-ce qu’un commit ? Un commit est l’état du code enregistré dans votre dépôt à un moment T, un instantané de tous les éléments dans votre dépôt au moment où vous effectuez le commit.

Allons donc maintenant ajouter un fichier dans la branche master de notre dépôt :

$ touch README.md
$ git add README.md

Créons maintenant un fichier vide nommé README.md. Nous utilisons ensuite la commande git add README.md afin d’ajouter le fichier sur la branche. Après cela, le nouvel état du dépôt est le suivant :

$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

new file: README.md

Nous observons que nous sommes toujours sur la branche master et qu’aucun commit n’a toujours été effectué sur cette branche. La section suivante indique par contre qu’un changement est désormais pris en compte par Git et qu’il s’agit d’un nouveau fichier nommé README.md.

Notion importante ici à retenir : la commande git add nous a permis de faire passer une modification – ici l’ajout d’un fichier – de l’état où ce fichier n’était pas pris en compte par Git vers un espace de travail, appelé ici “stage” , ce qui signifie donc que ce fichier est désormais surveillé par Git.

Premier commit

Premier grand événement de la vie de notre dépôt, nous allons maintenant effectuer notre premier commit avec la commande suivante :

$ git commit README.md -m "add README.md"
[master (root-commit) 505ace4] add README.md
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md

La command git commit nous permet de spécifier un fichier à prendre en compte pour le commit en question. Ici c’était facile, nous n’en avons qu’un. L’option -m accompagnée d’un texte permet de spécifier un message explicatif à associer à ce commit. Git nous retourne différentes informations sur le commit effectué puis nous vérifions de nouveau l’état du dépôt :

$ git status
On branch master
nothing to commit, working tree clean

Nous n’apprenons pas grand-chose. On peut remarquer que le message No commit yet a disparu. Nous allons passer une commande spécifique pour consulter l’historique des commits :

$ git log
commit 5c1b4e9826a147aa1e16625bf698b4d7af5eca9b
Author: Carl Chenet <chaica@ohmytux.com>
Date: Mon Apr 29 22:12:08 2019 +0200

add README.md

La commande git log nous apprend l’identifiant, l’auteur et la date du commit, suivi par le message explicatif dudit commit.

Pousser son commit vers le dépôt distant

Dans le premier article de cette série, nous avions créé un dépôt distant à partir duquel avait été cloné le dépôt local dans lequel nous venons de travailler. Il s’agit maintenant de synchroniser le dépôt distant avec le dépôt local . Pour cela, nous utilisons la commande suivante :

$ git push --set-upstream origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 220 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://gitlab.com/chaica/toto
* [new branch] master -> master
Branch master set up to track remote branch master from origin.

La commande git push nous permet de pousser nos modifications d’un dépôt local vers un dépôt distant. L’option –set-upstream permet d’indiquer que notre branche courante dans le dépôt local (désigné par le terme origin et qui est donc ici nommée master) sera poussée vers la branche du dépôt distant nommée elle aussi master. Cette option n’est obligatoire qu’à votre premier push.

Git nous indique ici [new branch] car, pour rappel, nous avions cloné un dépôt vide. Il créé donc la branche du dépôt distant nommé master. Refaisons appel à la commande git remote que nous avions déjà utilisée dans le premier article. En effet elle va nous permettre de mieux appréhender le rapport entre la branche locale et la branche distante :

$ git remote -v
origin https://gitlab.com/chaica/toto (fetch)
origin https://gitlab.com/chaica/toto (push)

Nous voyons sur la seconde ligne qu’en effet l’origine pour la branche en cours, ici l’url https://gitlab.com/chaica/toto, pour l’action push est bien notre dépôt distant .

Nous pouvons maintenant utiliser une version beaucoup plus simple de la commande git push se limitant à deux mots :

$ git push 
Everything up-to-date

Le message de Git est clair, notre dépôt local est à jour par rapport au dépôt distant. Nos récentes modifications, représentées au niveau de Git par le commit que nous venons de créer, ont été poussées vers le dépôt distant, assurant la redondance des données et permettant – nous le verrons plus tard dans quelques articles – le travail collaboratif.

Conclusion

Ce deuxième article sur comment débuter avec Git nous a permis de réaliser les toutes premières opérations d’ajouts de code sur notre dépôt local et de s’assurer de sa synchronisation avec le dépôt distant. Les notions de branche et de commit ont également été abordées pour la première fois. Dans un prochain article nous présenterons comment gérer un commit plus complexe.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre :

Mastodon : @carlchenet
Diaspora : @carlchenet
Twitter : @carl_chenet

Suivre l’actualité du Logiciel Libre et Open Source francophone

Abonnez-vous au Courrier du hacker, une newsletter hebdomadaire résumant le meilleur de l’actualité francophone du Logiciel Libre et Open Source. Déjà plus de 80 numéros et 2000 abonnés.