Git 1. Résumé (très) concis du (trop) strict minimum pour utiliser Git

Publication : 2019-11-15 vendredi

Dernière modification mineure : 2019-12-04 mercredi

Voici un mémo concernant quelques commandes Git à savoir sur le bout des doigts. Ce mémo ne remplacera pas pas la lecture à terme du Pro Git book téléchargeable ici.

On configure Git à sa première utilisation (source)

Sur un système d’exploitation avec un Git fraîchement installé, Git ne sait pas encore à qui il a affaire, ce qui l’empèche d’effectuer une traçabilité correcte. En effet, comment peut-il savoir à quel développeur attribuer vos actes si on ne lui a pas indiqué au préalable ?

Donc, lancer un terminal et taper :

$ git config --global user.name "Nicolas Floquet"
$ git config --global user.email nicolasfloquet@domaine.example
$ git config --global core.editor emacs

Je prends ici l’éditeur emacs comme exemple mais il faut évidemment le remplacer par son éditeur favori s’il ne s’agit pas de emacs pour vous. Par exemple gedit ou mousepad ou vim.

On initie un dépôt Git localement (source)

$ mkdir le/répertoire/de/mon/dépôt/git
$ cd le/répertoire/de/mon/dépôt/git
$ git init

Une routine de travail (trop) basique

Pour un usage sans collaborateurs, sans branches ni serveur ; éventuellement suffisant pour gérer quelques fichiers de configuration personnels de ses applications sous GNU/Linux (les fichiers de conf sont alors remplacés par des liens symboliques pointant vers les fichiers respectifs situés au sein de votre dépôt Git dédié).

Pour commencer $ cd le/répertoire/de/mon/dépôt/git, puis on entame le cycle suivant :

$ git status #pour vérifier où le système en est dans l'indexation des fichiers (au cas où on en aurait oublié lors de la dernière session de travail).
$ gedit monfichier.txt #c’est le travail proprement dit
$ git diff #pour vérifier si la modification effectuée correspond bien à ce qu’on a voulu faire, si on n’a pas introduit d’erreur par mégarde.
(facultatif) $ git status #pour constater que les fichiers modifiés ne sont pas encore indexés (en rouge).
$ git add monfichier.txt #pour indexer le ou les fichiers modifiés.
(facultatif) $ git status #pour constater que les fichiers modifiés sont désormais indexés (en vert).
$ git commit #pour terminer l’acte.
Et enfin, rédaction d’un petit texte explicatif dans un éditeur générer l'acte (=commit).
(facultatif) $git log #Pour admirer fièrement l’inscription dans le journal correspondant à notre dernier acte.

Et, on retourne à l’étape 1 !

On visualise l’historique des modifications de notre code (source)

Précision sémantique : log peut se traduire par « journal de bord » en français ; on va le comprendre ici par le mot historique.

git log bien sûr
- avec notament l’option -n (suivi d’un chiffre) pour limiter le nombre des commits affichés aux n derniers.
Mais surtout :
- git log --oneline
- git log --oneline --all --graph
- git log --all --graph --pretty="%C(auto)%h %Creset%ae %Cred%ad %C(auto)%d %Creset%s" --date=iso
  - --date=short est une bonne alternative.

On commence à travailler seul avec un serveur (source)

Si on dispose d’un accès à un serveur pour y placer un dépôt Git « central », on introduit alors les commandes suivantes dans son cycle de travail :

$ git clone (adresse du serveur) #une fois pour toute, afin de créer sa copie locale associée à l’original distant du dépôt (=un clone)
- par exemple $ git clone https://deontobox.org/forge/nflqt/Libre_et_Sante.git #pour cloner le dépôt des fichiers de ma conférence Libre et Santé avec le protocole HTTPS
- ou $ git clone gitea@deontobox.org:nflqt/Libre_et_Sante.git #si on a un accès via le protocole SSH à la forge Gitea de mon projet Déontobox.
$ git push # pour « pousser » nos derniers actes (=/commits/) sur le dépôt distant « central ».