Logs
Consultez les logs.
OK
Liste des données
Consultez la liste des données.
OK
Loading...
Formulaire
Saisissez vos données.
Enregistrer
Annuler
ReadyDev
Présentation
Admin
Git s'impose de plus en plus comme la norme de facto pour la gestion du contrôle de version dans le développement logiciel moderne. Développé à l'origine par Linus Torvalds comme système de contrôle de version pour le noyau Linux en remplacement du système de contrôle de version propriétaire BitKeeper, Git a depuis conquis la majeure partie du monde open source et est également utilisé par de nombreuses organisations pour leurs projets privés et propriétaires. Ce tutoriel est pensé pour vous donner des recettes pratiques pour l'utilisation quotidienne de Git. Ces recettes peuvent être utilisées directement ou comme source d'inspiration. Ce tutoriel se veut aborder le modèle de données Git à travers des recettes pratiques et des explications détaillées pour vous permettre de mieux comprendre son fonctionnement interne. Ce tutoriel aborde les sujets suivants :
Utilisation de l'historique. Avec Git, tout l'historique est stocké localement. Vous pouvez effectuer des recherches dans l'historique, l'afficher, trouver le dernier commit sur une branche donnée, et bien plus encore ;
Utilisation efficace des branches grâce aux options et stratégies pour les pousser, les tirer et les fusionner ;
Stockage et extraction de métadonnées supplémentaires dans le dépôt Git.
Reprise après sinistre : locale et globale.
Le guide de contrôle de version Git vous fournit des instructions précises, étape par étape, pour diverses opérations Git courantes et moins courantes. Ce tutoriel facilitera votre travail quotidien avec Git en fournissant des solutions aux problèmes courants, des conseils et astuces utiles, ainsi que des explications détaillées sur leur fonctionnement.
Définitions
Outils :
Git est système de contrôle de version distribué.
Gitk est un navigateur de dépôts graphique pour Git.
Concepts :
.gitignore est un fichier pour la configuration des fichiers à ignorer dans Git.
glob est une expression régulière simplifiée pour le fichier (.gitignore).
alias est un raccourci de commande pour Git.
commit est une capture de l'état d'un projet à un instant donné pour Git.
tag est une référence à un commit spécifique pour Git.
Premiers pas
Installation de Git (binaires)
On exécute la commande (yum, install) pour installer Git sous Fedora.
... $ sudo yum install git ...
On exécute la commande (apt, install) pour installer Git sous Ubuntu.
... $ sudo apt install git ...
On suit les instructions suivantes pour installer Git sous Mac.
... - On télécharge l'installateur de Git pour Mac, A l'adresse (https://git-scm.com/downloads/mac) - On lance l'installateur de Git sous Mac. - On suit les instructions pour installer Git sous Mac. ...
On suit les instructions suivantes pour installer Git sous Windows.
On note que :
On note que :
Il s'agit d'un projet appelé (Git for Windows), également appelé (msysGit), distinct de Git lui-même.
Le programme d'installation inclut une version en ligne de commande de Git ainsi que l'interface graphique.
Il fonctionne également bien avec Powershell et configure une mise en cache des identifiants fiable et des paramètres CRLF cohérents.
... - On télécharge l'installateur de Git pour Windows, A l'adresse (https://git-scm.com/downloads/win) - On lance l'installateur de Git sous Windows. - On suit les instructions pour installer Git sous Windows. ...
Installation de Git (sources)
On exécute la commande (yum, install) pour installer les dépendances nécessaires à l'installation de Git depuis les sources sous Fedora.
... $ sudo yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel ...
On exécute la commande (apt, install) pour installer les dépendances nécessaires à l'installation de Git depuis les sources sous Ubuntu.
... $ sudo apt install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev ...
On se rend à l'adresse (https://www.kernel.org/pub/software/scm/git/) pour récupérer le sources de la dernière archive tar étiquetée de la version de Git sur le site (Kernel.org).
On note que :
On note que :
On peut aussi récupérer la dernière archive tar étiquetée de la version de Git sur le site (GitHub.org) à l'adresse (https://github.com/git/git/tags).
On exécute la commande (tar, zxf) pour décompresser l'archive de Git.
On exécute la commande (cd) pour se déplacer dans le dossier Git décompressé.
On exécute la commande (make, configure) pour générer le script de configuration (configure) de Git.
On exécute le script (configure, prefix) pour initialiser le répertoire d'installation de Git.
On exécute la commande (make, all, doc, info) pour construire les binaires Git et sa documentation.
On exécute la commande (make, install) pour installer les binaires Git et sa documentation sur le système.
... $ tar -zxf git-1.9.1.tar.gz $ cd git-1.9.1 $ make configure $ ./configure --prefix=/usr $ make all doc info $ sudo make install install-doc install-html install-info ...
On peut exécuter la commande (git, clone) pour mettre à jour les sources de Git à partir du dossier Git décompressé.
... $ git clone git://git.kernel.org/pub/scm/git/git.git ...
Configuration de Git
On exécute la commande (git, config, global, user.name) pour configurer le nom de l'utilisateur (John Doe) ayant effectué les modifications.
On exécute la commande (git, config, global, user.email) pour configurer l'adresse email de l'utilisateur (johndoe@example.com) ayant effectué les modifications.
On note que :
On note que :
L'option (global) permet d'enregistrer les configurations dans le répertoire d'accueil (HOME) de l'utilisateur courant à l'emplacement (~/.gitconfig) ou (~/.config/git/config) sous Linux.
L'option (system) permet d'enregistrer les configurations dans le répertoire des configurations système à l'emplacement (/etc/gitconfig) sous Linux.
L'option (local) permet d'enregistrer les configurations dans le répertoire Git du dépôt courant à l'emplacement (.git/config) sous Linux.
... $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ...
On exécute la commande (git, config, global, core.editor) pour configurer l'éditeur Git pour les messages de commit.
On note que :
On note que :
Git utilisera l'éditeur par défaut du système si cette opération n'est pas effectuée.
... $ git config --global core.editor emacs ...
On exécute la commande (git, config, list) pour lister les configurations Git.
... $ git config --list ... user.name=John Doe user.email=johndoe@example.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ...
On exécute la commande (git, config, user.name) pour afficher le nom de l'utilisateur Git courant.
On note que :
On note que :
On peut procéder de la même façon pour vérifier la valeur d'une clé quelconque.
... $ git config user.name ... John Doe ...
Aide sur une commande Git
On peut exécuter la commande (git, help, COMMAND) pour obtenir l'aide sur une commande Git.
On peut exécuter la commande (git, COMMAND, help) pour obtenir l'aide sur une commande Git.
On peut exécuter la commande (man, git, COMMAND) pour obtenir l'aide sur une commande Git sous Linux.
... $ git help <verb> $ git <verb> --help $ man git-<verb> ...
On exécute la commande (git, help, config) pour obtenir l'aide sur la commande (git, config).
... $ git help config ...
Bases de Git
Initialisation du répertoire Git
On exécute la commande (git, init) pour initialiser le répertoire courant comme un répertoire Git afin de pouvoir le suivre dans Git.
On note que :
On note que :
Cette commande crée un nouveau sous-répertoire nommé (.git) dans le répertoire courant pour gérer le suivi des fichiers dans Git.
On note que :
On note que :
À ce stade, aucun élément de votre projet n'est encore suivi.
... $ git init ...
Indexation de fichiers
On exécute la commande (git, add, REGEX) pour indexer les fichiers selon le modèle (*.c).
On exécute la commande (git, add, FILE) pour indexer le fichier (LICENSE).
On exécute la commande (git, commit, m) pour valider les modifications avec le message de commit (initial project version).
On note que :
On note que :
Les modifications sont validées dans un instantané.
Seuls les modifications indexées par la commande (git, add) seront présentes dans cet instantané.
... $ git add *.c $ git add LICENSE $ git commit -m 'initial project version' ...
Clonage de dépôt
On exécute la commande (git, clone) pour cloner le dépôt (libgit2).
On note que :
On note que :
Cela nous permet de pouvoir contribuer au projet (libgit2).
On note que :
On note que :
La commande (git, clone) fait une copie complète de la quasi-totalité des données du dépôt distant et non une simple copie superficielle comme c'est le cas dans certains contrôleurs de version qui utilise la commande (checkout).
La commande (git, clone) récupère chaque version de chaque fichier de l'historique du projet. Cela signifie que si le disque de votre serveur est corrompu, vous pouvez souvent utiliser presque n'importe quel clone sur n'importe quel client pour rétablir l'état du serveur lors du clonage (vous risquez de perdre certains hooks côté serveur, mais toutes les données versionnées seront conservées). Ce qui n'est pas possible dans certains contrôleurs de version.
On note que :
On note que :
Cela crée un répertoire nommé (libgit2), initialise un répertoire (.git) à l'intérieur, récupère toutes les données de ce dépôt et extrait une copie de travail de la dernière version.
Si vous accédez au nouveau répertoire (libgit2), vous y trouverez les fichiers du projet, prêts à être utilisés.
On note que :
On note que :
Il est possible de cloner le dépôt dans un répertoire autre que (libgit2) en spécifiant le (nouveau répertoire) comme option de ligne de commande.
... $ git clone https://github.com/libgit2/libgit2 ...
On exécute la commande (git, clone) pour cloner le dépôt (libgit2) dans le répertoire (mylibgit).
... $ git clone https://github.com/libgit2/libgit2 mylibgit ...
On jette un coup d'oeil sur la figure suivante pour comprendre le cycle de vie des fichiers suivis dans Git.
On note que :
On note que :
La commande (git, add) sur un fichier à l'état (Untracked, Non suivi) fait passé le fichier à l'état (Staged, Indexé, Suivi, Mise en scène, Préparé).
La commande (git, commit) sur un fichier à l'état (Staged, Indexé, Suivi, Mise en scène, Préparé) fait passer le fichier à l'état (Unmodified, Non modifié).
L'opération (Edit the file, édition d'un fichier) sur un fichier à l'état (Unmodified, Non modifié) fait passer le fichier à l'état (Modified, Modifié).
La commande (git, add) sur un fichier à l'état (Modified, Modifié) fait passer le fichier à l'état (Staged, Indexé, Suivi, Mise en scène, Préparé).
La commande (git, rm) sur un fichier à l'état (Unmodified, Non modifié) fait passer le fichier à l'état (Untracked, Non suivi).
Affichage de l'état
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On note que :
On note que :
Cela permet de déterminer l'état dans lequel se trouve chaque fichier du répertoire de travail.
On note que :
On note que :
L'expression (On branch master) indique la branche sur laquelle vous vous trouvez et vous informe qu'elle n'a pas divergé de la même branche sur le serveur. Pour l'instant, cette branche est toujours « master », ce qui est la valeur par défaut.
L'expression (nothing to commit, working directory clean) indique que votre répertoire de travail est propre ; autrement dit, il ne contient aucun fichier suivi ni modifié. Git ne voit aucun fichier non suivi, sinon ils seraient listés ici.
... $ git status ... On branch master nothing to commit, working directory clean ...
On exécute la commande (echo) pour créer un fichier (README) avec le texte (My Project).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (README) n'est pas suivi, car il se trouve sous la rubrique (Untracked files, Fichiers non suivis) dans la de l'état du répertoire de travail.
On note que :
On note que :
Être non suivi signifie que Git voit un fichier que vous n'aviez pas dans l'instantané précédent (commit).
Git ne commencera pas à l'inclure dans vos instantanés de commit tant que vous ne le lui aurez pas explicitement demandé.
Cela permet d'éviter que vous n'incluiez accidentellement des fichiers binaires générés ou d'autres fichiers que vous ne vouliez pas inclure.
...
$ echo 'My Project' > README
$ git status
...
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
...On exécute la commande (git, add) pour indexer le fichier (README).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (README) est dans un état intermédiaire car il se trouve sous la rubrique (Changes to be committed, Modifications à valider).
Si vous validez à ce stade, la version du fichier (README) au moment de l'exécution de la commande (git, add) sera celle qui figurera dans l'historique.
...
$ git add README
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
...On exécute la commande (vim) pour modifier le fichier (benchmarks.rb) déjà suivi.
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (benchmarks.rb) apparaît dans une section intitulée (Changes not staged for commit, Modifié mais non soumis à validation), ce qui signifie qu'un fichier suivi a été modifié dans le répertoire de travail, mais pas encore soumis à validation.
...
$ vim benchmarks.rb
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: benchmarks.rb
...On exécute la commande (git, add) pour indexer le fichier (benchmarks.rb).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On note que :
On note que :
Le fichier (benchmarks.rb) sera ajouté au prochain commit.
On note que :
On note que :
La commande (git, add) est une commande polyvalente : elle permet de suivre les nouveaux fichiers, de les soumettre à validation et, par exemple, de marquer les fichiers en conflit de fusion comme résolus.
Il peut être plus judicieux de considérer la commande (git, add) comme (ajouter ce contenu au prochain commit) plutôt que comme (ajouter ce fichier au projet).
On constate que :
On constate que :
Les deux fichiers (README, benchmarks.rb) sont indexés et seront inclus dans votre prochain commit.
...
$ git add benchmarks.rb
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: benchmarks.
...On exécute la commande (vim) pour modifier le fichier (benchmarks.rb).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On suppose que :
On suppose que :
Vous souveniez d'une petite modification à apporter au fichier (benchmarks.rb) avant de le commiter. Vous l'ouvrez à nouveau, effectuez cette modification et vous êtes prêt à le commiter.
On constate que :
On constate que :
Le fichier (benchmarks.rb) est répertorié comme étant à la fois (modifié, indexé) car il se trouve sous la rubrique (Changes to be committed, Modifications à valider) et (modifié, non indexé) car il apparaît dans la section (Changes not staged for commit, Modifié mais non soumis à validation).
On note que :
On note que :
Git indexe un fichier exactement tel qu'il est lorsque vous exécutez la commande (git, add).
Si vous effectuez un commit maintenant, la version de (benchmarks.rb) telle qu'elle était lors de la dernière exécution de la commande (git, add) sera celle qui apparaîtra dans le commit, et non la version du fichier telle qu'elle apparaît dans votre répertoire de travail lorsque vous exécutez la commande (git, commit).
Si vous modifiez un fichier après avoir exécuté la commande (git, add), vous devez relancer la commande (git, add) pour indexer la dernière version du fichier.
...
$ vim benchmarks.rb
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: benchmarks.rb
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: benchmarks.rb
...On exécute la commande (git, add) pour indexer le fichier (benchmarks.rb).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On note que :
On note que :
La commande (git, add) indexe la dernière version du fichier (benchmarks.rb).
On constate que :
On constate que :
Le fichier (benchmarks.rb) est répertorié comme étant uniquement (modifié, indexé) car il se trouve sous la rubrique (Changes to be committed, Modifications à valider).
...
$ git add benchmarks.rb
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: benchmarks.rb
...On exécute la commande (git, status, s) pour afficher l'état court du répertoire de travail.
On note que :
On note que :
La commande (git, status, s ou short) permet d'afficher l'état du répertoire de travail de manière plus courte et concise afin d'obtenir une sortie beaucoup plus simplifiée.
On note que :
On note que :
Une ligne d'information dans la sortie suit la structure (XY FILE).
Les colonnes (XY) indiquent l'état du fichier (FILE).
La colonne de gauche (X) indique l'état du fichier dans la zone d'indexation et la colonne de droite (Y) indique l'état du fichier dans le répertoire de travail.
On note que :
On note que :
Les nouveaux fichiers non suivis sont signalés par (?).
Les nouveaux fichiers ajoutés à la zone de préparation sont signalés par (A).
Les fichiers modifiés sont signalés par (M).
On constate que :
On constate que :
Le fichier (README, M) est à l'état (modifié, non indexé).
Le fichier (Rakefile, MM) est à l'état (modifié, non indexé) et à l'état (modifié, indexé).
Le fichier (lib/git.rb, A) est à l'état (nouveau fichier indexé).
Le fichier (lib/simplegit.rb, M) est à l'état (modifié, non indexé).
Le fichier (LICENSE.txt, ??) est à l'état (fichier non suivi).
... $ git status -s $ git status --short ... M README MM Rakefile A lib/git.rb M lib/simplegit.rb ?? LICENSE.txt ...
On jette un coup d'oeil sur le tableau suivant pour comprendre la structure des informations de sortie de la commande (git, status, s).
On note que :
On note que :
Une ligne d'information dans la sortie suit la structure (XY FILE).
Les colonnes (XY) indiquent l'état du fichier (FILE).
La colonne de gauche (X) indique l'état du fichier dans la zone d'indexation et la colonne de droite (Y) indique l'état du fichier dans le répertoire de travail.
...
La colonne X ou Y peut prendre une des valeurs suivantes
-------------------------------------------------
[ ] = unmodified
[M] = modified
[T] = file type changed (regular file, symbolic link or submodule)
[A] = added
[D] = deleted
[R] = renamed
[C] = copied (if config option status.renames is set to "copies")
[U] = updated but unmerged
[?] = untracked
=================================================
Les colonnes X et Y peuvent prendre les valeurs suivantes
-------------------------------------------------
X Y Meaning
-------------------------------------------------
[AMD] not updated
M [ MTD] updated in index
T [ MTD] type changed in index
A [ MTD] added to index
D deleted from index
R [ MTD] renamed in index
C [ MTD] copied in index
[MTARC] index and work tree matches
[ MTARC] M work tree changed since index
[ MTARC] T type changed in work tree since index
[ MTARC] D deleted in work tree
R renamed in work tree
C copied in work tree
-------------------------------------------------
D D unmerged, both deleted
A U unmerged, added by us
U D unmerged, deleted by them
U A unmerged, added by them
D U unmerged, deleted by us
A A unmerged, both added
U U unmerged, both modified
-------------------------------------------------
? ? untracked
! ! ignored
-------------------------------------------------
...Gestion de fichiers à ignorer
On exécute la commande (cat) pour afficher le contenu du fichier (.gitignore).
On note que :
On note que :
Le fichier (.gitignore) sert à configurer les fichiers que Git souhaite ignorer ; c'est-à-dire qu'il ne souhaite pas ajouter automatiquement, ni même afficher comme non suivis. - Il s'agit de fichiers générés automatiquement, tels que des fichiers journaux ou des fichiers produits par votre système de build.
Dans ce cas, vous pouvez créer un fichier (.gitignore) listant les modèles correspondants.
On constate que :
On constate que :
La première ligne (*.[oa]) indique à Git d'ignorer tous les fichiers se terminant par (.o) ou (.a). Il s'agit de fichiers objets et archives pouvant résulter de la compilation de votre code.
La deuxième ligne (*~) indique à Git d'ignorer tous les fichiers se terminant par un tilde (~), utilisé par de nombreux éditeurs de texte comme Emacs pour marquer les fichiers temporaires.
Vous pouvez également inclure un répertoire (log, tmp ou pid) ; une documentation générée automatiquement ; etc.
On note que :
On note que :
Il est généralement judicieux de configurer un fichier (.gitignore) avant de commencer le projet afin d'éviter de valider accidentellement des fichiers indésirables dans votre dépôt Git.
... $ cat .gitignore ... *.[oa] *~ ...
On jette un coup d'oeil sur les instructions (.gitignore) suivantes pour comprendre la structure des règles de configuration du fichier (.gitignore).
On note que :
On note que :
Les lignes (vides) ou commençant par (#) sont ignorées ; elles sont considérées comme des commentaires.
Les motifs (glob) standards fonctionnent.
Vous pouvez terminer les motifs par une barre oblique (/) pour spécifier un répertoire.
Vous pouvez interdire d'ignorer un motif en le commençant par un point d'exclamation (!).
On note que :
On note que :
Les motifs (glob) sont comme des expressions régulières simplifiées utilisées par les shells.
Un astérisque (*) correspond à zéro ou plusieurs caractères.
[abc] correspond à tout caractère entre crochets (ici a, b ou c).
Un point d'interrogation (?) correspond à un seul caractère.
Les crochets encadrant des caractères séparés par un tiret ([0-9]) correspondent à tout caractère entre eux (ici de 0 à 9).
Vous pouvez également utiliser deux astérisques pour correspondre à des répertoires imbriqués ; (a/**/z) correspond à (a/z), (a/b/z), (a/b/c/z), etc.
On note que :
On note que :
GitHub propose une liste assez complète d'exemples de fichiers (.gitignore) pertinents pour des dizaines de projets et de langages sur (https://github.com/github/gitignore) si vous souhaitez un point de départ pour votre projet.
... # a comment - this is ignored *.a # no .a files !lib.a # but do track lib.a, even though you're ignoring .a files above /TODO # only ignore the root TODO file, not subdir/TODO build/ # ignore all files in the build/ directory doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt ...
Affichage des différences
On exécute la commande (vim) pour modifier le fichier (README).
On exécute la commande (vim) pour modifier le fichier (benchmarks.rb).
On exécute la commande (git, add) pour indexer le fichier (README).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (README, Changes to be committed, new file) est nouveau et indexé.
Le fichier (benchmarks.rb, Changes not staged for commit, modified) est modifié, mais pas encore indexé.
...
$ vim README
$ vim benchmarks.rb
$ git add README
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: benchmarks.rb
...On exécute la commande (git, diff) pour voir les modifications présentes dans la zone de travail.
On note que :
On note que :
La commande (git, diff) permet de voir ce qui a été modifié mais pas encore indexé.
On constate que :
On constate que :
Le fichier (benchmarks.rb) possède des modifications dans le répertoire de travail.
...
$ git diff
...
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end
+ run_code(x, 'commits 1') do
+ git.commits.size
+ end
+
run_code(x, 'commits 2') do
log = git.commits('master', 15)
log.size
...On exécute la commande (git, diff, staged) pour voir les modifications présentes dans la zone d'indexation par rapport au dernier commit.
On note que :
On note que :
La commande (git, diff, staged) permet de voir ce qui a été indexé et qui sera intégré au prochain commit.
On constate que :
On constate que :
Le fichier (README) possède des modifications dans la zone d'indexation.
... $ git diff --staged ... diff --git a/README b/README new file mode 100644 index 0000000..03902a1 Chapter 2 - Git Basics 22 --- /dev/null +++ b/README @@ -0,0 +1,4 @@ +My Project + + This is my project and it is amazing. + ...
On exécute la commande (git, add) pour indexer le fichier (benchmarks.rb).
On exécute la commande (echo) pour modifier le fichier (benchmarks.rb).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (benchmarks.rb) est à l'état modifié indexé (Changes to be committed, modified) et à l'état modifié non indexé (Changes not staged for commit, modified).
...
$ git add benchmarks.rb
$ echo '# test line' >> benchmarks.rb
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: benchmarks.rb
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working
directory)
modified: benchmarks.rb
...On exécute la commande (git, diff) pour voir les modifications présentes dans la zone de travail.
On constate que :
On constate que :
Le fichier (benchmarks.rb) possède des modifications dans la zone de travail.
On note que :
On note que :
La commande (git, diff) renvoie le texte non indexé uniquement (+# test line).
On note que :
On note que :
La commande (git, diff) n'affiche pas toutes les modifications apportées depuis votre dernier commit, mais uniquement celles qui ne sont pas encore indexées.
Cela peut prêter à confusion, car si vous avez indexé toutes vos modifications, la commande (git, diff) ne vous affichera aucune sortie.
... $ git diff ... diff --git a/benchmarks.rb b/benchmarks.rb index e445e28..86b2f7c 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -127,3 +127,4 @@ end main() ##pp Grit::GitRuby.cache_client.stats +# test line ...
On exécute la commande (git, diff, cached) pour voir les modifications présentes dans la zone d'indexation par rapport au répertoire de travail.
On constate que :
On constate que :
Le fichier (benchmarks.rb) possède des modifications dans la zone d'indexation.
La commande (git, diff, cached) renvoie le texte indexé uniquement jusqu'à présent (+ run_code, ..., + end).
Le texte non indexé (+# test line) n'est pas renvoyé.
...
$ git diff --cached
...
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end
+ run_code(x, 'commits 1') do
+ git.commits.size
+ end
+
run_code(x, 'commits 2') do
log = git.commits('master', 15)
log.size
...Valider les modifications
On exécute la commande (git, commit) pour valider les modifications.
On note que :
On note que :
Tout ce qui n'est pas encore indexé (c'est-à-dire, les fichiers que vous avez créés ou modifiés et sur lesquels vous n'avez pas exécuté la commande (git, add) depuis leur modification) ne sera pas inclus dans ce commit. Ils resteront comme des fichiers modifiés dans le répertoire de travail.
On suppose que :
On suppose que :
La dernière fois que vous avez exécuté la commande (git, status), vous avez constaté que tout était indexé ; vous êtes donc prêt à valider vos modifications.
On constate que :
On constate que :
La commande (git, commit) lance l'éditeur de votre choix.
Le message de validation par défaut contient la dernière sortie de la commande (git, status) commentée, avec une ligne vide au-dessus.
Vous pouvez supprimer ces commentaires et saisir votre message de validation, ou les laisser pour vous aider à mémoriser ce que vous validez.
On note que :
On note que :
L'éditeur lancé par la commande (git, commit) est défini par la variable d'environnement ($EDITOR) de votre shell, généralement vim ou emacs.
Vous pouvez configurer l'éditeur de votre choix avec la commande (git, config, global, core.editor).
... $ git commit ...
On jette un coup d'oeil sur le texte suivant pour visualiser la structure du message de commit par défaut.
... # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # new file: README # modified: benchmarks.rb # ~ ~ ~ ".git/COMMIT_EDITMSG" 9L, 283C ...
On exécute la commande (git, commit, m) pour valider les modifications avec le message de commit (Story 182: Fix benchmarks for speed).
On constate que :
On constate que :
Le commit vous a fourni des informations sur lui-même : la branche sur laquelle vous avez effectué le commit (master), sa somme de contrôle SHA-1 (463dc4f), le nombre de fichiers modifiés (2 files changed) et des statistiques sur les lignes ajoutées (2 insertions(+)) et supprimées (, 0 deletions(-)).
On note que :
On note que :
Le commit enregistre l'instantané que vous avez configuré dans votre zone d'indexation.
Tout ce qui n'a pas indexé reste inchangé. Vous pouvez effectuer un autre commit pour l'ajouter à votre historique.
Chaque commit enregistre un instantané de votre projet que vous pouvez consulter ou comparer ultérieurement.
... $ git commit -m "Story 182: Fix benchmarks for speed" ... [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 README ...
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On exécute la commande (git, commit, a, m) pour indexer automatiquement tous les fichiers suivis et valider les modifications avec le message de commit (added new benchmarks). On constate que :
La commande (git, status) indique que :
Le fichier (benchmarks.rb) est à l'état modifié non indexé ; il s'agit d'un fichier déjà suivi qui possède des modifications non indexées ; il est le seul fichier dans cet état. On constate que :
La commande (git, commit, a, m) indique que :
Un seul fichier a été automatiquement indexé et validé (1 file changed) à la suite de l'exécution de la commande (git, commit, a, m).
...
$ git status
...
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: benchmarks.rb
no changes added to commit (use "git add" and/or "git commit -a")
...
$ git commit -a -m 'added new benchmarks'
...
[master 83e38c7] added new benchmarks
1 file changed, 5 insertions(+), 0 deletions(-)
...Suppression de fichiers
On exécute la commande (rm) pour supprimer le fichier (grit.gemspec).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (grit.gemspec) est à l'état supprimé non indexée.
...
$ rm grit.gemspec
$ git status
...
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: grit.gemspec
no changes added to commit (use "git add" and/or "git commit -a")
...On exécute la commande (git, rm) pour supprimer le fichier (grit.gemspec).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
La commande (git, rm) exécute la commande (rm) en interne.
Le fichier (grit.gemspec) est à l'état supprimé indexé.
On note que :
On note que :
La commande (git, rm) supprime le fichier du disque dur ; puis indexe sa suppression dans Git.
Lors de votre prochain commit, le fichier disparaîtra et ne sera plus suivi.
On note que :
On note que :
Si vous l'avez déjà modifié et indexé, vous devez forcer sa suppression avec l'option (-f). Il s'agit d'une mesure de sécurité permettant d'éviter la suppression accidentelle de données non encore enregistrées dans un instantané et irrécupérables depuis Git.
...
$ git rm grit.gemspec
...
rm 'grit.gemspec'
...
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: grit.gemspec
...
$ git rm -f grit.gemspec
...On exécute la commande (git, rm, cached) pour supprimer le fichier (README) du suivi tout en le conservant.
On note que :
On note que :
Cela conserve le fichier sur le disque dur sans que Git ne le suive.
... $ git rm --cached README ...
On exécute la commande (git, rm) pour supprimer les fichiers (*.log ).
On note que :
On note que :
Cette commande supprime tous les fichiers qui se terminent par (.log).
La barre oblique inverse (\) devant le (*) est nécessaire car Git gère sa propre extension de nom de fichier, en plus de celle de votre shell.
Cette commande supprime tous les fichiers portant l'extension (.log) dans le répertoire (log/).
... $ git rm log/\*.log ...
On exécute la commande (git, rm) pour supprimer les fichiers (*~).
On note que :
On note que :
Cette commande supprime tous les fichiers qui se terminent par (~).
... $ git rm \*~ ...
Renommage de fichiers
On exécute la commande (git, mv) pour renommer le fichier (file_from) en (file_to).
On note que :
On note que :
Cette commande renomme le fichier sur le disque dur ; puis indexe son renommage dans Git.
On note que :
On note que :
Contrairement à certains contrôleurs de version, Git ne suit pas explicitement les déplacements de fichiers.
Si vous renommez un fichier dans Git, aucune métadonnée n'est stockée dans Git pour indiquer que vous avez renommé le fichier ; cependant, Git est assez intelligent pour le détecter a posteriori.
... $ git mv file_from file_to ...
On exécute la commande (git, mv) pour renommer le fichier (README.md) en (README).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (README.md, Changes to be committed, renamed) est à l'état renommé indexé.
...
$ git mv README.md README
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
...On jette un coup d'oeil sur les commandes suivantes pour comprendre l'équivalence de la commande (git, mv).
On constate que :
On constate que :
On exécute une commande (mv, FILE_1, FILE_2).
On exécute une commande (git, rm, FILE_1).
On exécute une commande (git, add, FILE_2).
... $ mv README.md README $ git rm README.md $ git add README ...
Affichage de l'historique des commits
On exécute la commande (git, clone) pour clone le dépôt (simplegit-progit).
... git clone https://github.com/schacon/simplegit-progit ...
On exécute la commande (git, log) pour afficher l'historique des commits dans le dépôt (simplegit-progit) afin de revenir en arrière pour voir ce qui s'est passé.
On note que :
On note que :
La commande (git, log) liste les commits effectués dans ce dépôt par ordre chronologique inverse, c'est-à-dire que les commits les plus récents apparaissent en premier.
On constate que :
On constate que :
La commande (git, log) liste chaque commit avec : - sa somme de contrôle SHA-1 (ca82a6dff817ec66f44342007202690a93763949), - le nom et l'adresse e-mail de l'auteur (Scott Chacon ), - la date de rédaction (Mon Mar 17 21:52:11 2008 -0700) - et le message de commit (changed the version number).
... $ git log ... commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 10:31:28 2008 -0700 first commit ...
On exécute la commande (git, log, p) pour afficher les différences des commits.
On note que :
On note que :
On affiche la différence introduite à chaque commit avec l'option (-p).
On limite la sortie aux deux derniers commits avec l'option (-2).
On note que :
On note que :
L'option (-p) est très utile pour la révision de code ou pour parcourir rapidement le déroulement d'une série de commits ajoutés par un collaborateur.
... $ git log -p -2 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the verison number diff --git a/Rakefile b/Rakefile index a874b73..8f94139 100644 --- a/Rakefile +++ b/Rakefile @@ -5,7 +5,7 @@ require 'rake/gempackagetask' spec = Gem::Specification.new do |s| s.platform = Gem::Platform::RUBY s.name = "simplegit" - s.version = "0.1.0" + s.version = "0.1.1" s.author = "Scott Chacon" s.email = "schacon@gee-mail.com" s.summary = "A simple gem for using Git in Ruby code." commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test diff --git a/lib/simplegit.rb b/lib/simplegit.rb index a0a60ae..47c6340 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -18,8 +18,3 @@ class SimpleGit end end - -if $0 == __FILE__ - git = SimpleGit.new - puts git.show -end \ No newline at end of file ...
On exécute la commande (git, log, stat) pour afficher les statistiques des commits.
On note que :
On note que :
La commande (git, log, stat) permet d'afficher sous chaque entrée de commit la liste des fichiers modifiés, le nombre de fichiers modifiés et le nombre de lignes ajoutées et supprimées.
On constate que :
On constate que :
Pour le commit (ca82a6dff817ec66f44342007202690a93763949) on a :
La liste des fichiers modifiés (Rakefile). - Le nombre de fichiers modifiés (1 file changed).
Le nombre de lignes ajoutées (1 insertion(+)).
Le nombre de lignes supprimées (1 deletion(-)).
... $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the verison number Rakefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test lib/simplegit.rb | 5 ----- 1 file changed, 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 10:31:28 2008 -0700 first commit README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ lib/simplegit.rb | 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+) ...
On exécute la commande (git, log, pretty, oneline) pour afficher les commits sur une seule ligne.
On note que :
On note que :
Cette option permet d'afficher chaque commit sur une seule ligne.
Cette option est utile si vous traitez de nombreux commits.
... $ git log --pretty=oneline ... ca82a6dff817ec66f44342007202690a93763949 changed the verison number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ...
On exécute la commande (git, log, pretty, format) pour afficher les commits selon le format (%h - %an, %ar : %s).
On note que :
On note que :
Cette option permet de préciser votre propre format de sortie de journal.
Cette option est particulièrement utile lorsque vous générez une sortie pour l'analyse automatique.
Comme vous spécifiez le format, vous savez qu'il ne changera pas avec les mises à jour de Git.
... $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 6 years ago : changed the version number 085bb3b - Scott Chacon, 6 years ago : removed unnecessary test a11bef0 - Scott Chacon, 6 years ago : first commit ...
On jette un coup d'oeil sur le tableau suivant pour comprendre les options de la chaine de format dans la commande (git, log, pretty, format).
On note que :
On note que :
L'auteur est la personne qui a initialement rédigé le travail (%an).
Le validateur (commiter) est la personne qui l'a appliqué en dernier (%cn).
Ainsi, si vous envoyez un correctif à un projet et qu'un des membres principaux l'applique, vous en êtes tous deux crédités : vous en tant qu'auteur, et le membre principal en tant que validateur.
... $ git log --pretty=format:"%h - %an, %ar : %s" ... ca82a6d - Scott Chacon, 6 years ago : changed the version number ... ============================================= Option--------Description de la sortie ============================================= %H------------Hachage de validation %h------------Hachage de validation abrégé %T------------Hachage d'arborescence %t------------Hachage d'arborescence abrégé %P------------Hachage parent %p------------Hachage parent abrégé %an-----------Nom de l'auteur %ae-----------Email de l'auteur %ad-----------Date de l'auteur (format respectant l'option -date=) %ar-----------Date de l'auteur, relative %cn-----------Nom du commiter %ce-----------Email du commiter %cd-----------Date du commiter %cr-----------Date du commiter, relative %s------------Sujet ============================================= ...
On exécute la commande (git, log, pretty, format, graph) pour afficher les commits avec un graphe de branches et fusions.
On note que :
On note que :
L'option (--graph) permet d'ajouter un joli petit graphique ASCII affichant l'historique de vos branches et de vos fusions.
... $ git log --pretty=format:"%h %s" --graph ... * 2d3acf9 ignore errors from SIGCHLD on trap * 5e3ee11 Merge branch 'master' of git://github.com/dustin/grit |\ | * 420eac9 Added a method for getting the current branch. * | 30e367c timeout code and tests * | 5a09431 add timeout protection to grit * | e1193f8 support for heads with slashes in them |/ * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local ...
On jette un coup d'oeil sur le tableau suivant pour résumer quelques options de la commande (git, log).
...
=============================================
Option----------------Description
=============================================
-p--------------------Afficher le correctif appliqué à chaque commit.
--stat----------------Afficher les statistiques des fichiers modifiés à
chaque commit.
--shortstat-----------Afficher uniquement les lignes de
modifications/insertions/suppressions de la
commande --stat.
--name-only-----------Afficher la liste des fichiers modifiés
après le commit.
--name-status---------Afficher également la liste des fichiers concernés,
avec les informations ajoutées/modifiées/supprimées.
--abbrev-commit-------Afficher uniquement les premiers caractères de la
somme de contrôle SHA-1 au lieu des 40.
--relative-date-------Afficher la date au format relatif
(par exemple," 2 weeks ago") au lieu du format complet.
--graph---------------Afficher un graphique ASCII de l'historique des
branches et des fusions à côté
de la sortie du journal.
--pretty--------------Afficher les commits dans un format alternatif.
Les options incluent oneline, short, full, fuller et
format (où vous spécifiez votre propre format).
=============================================
...On exécute la commande (git, log, since) pour afficher la liste des commits effectués depuis les deux dernières semaines (2.weeks).
On note que :
On note que :
Cette commande fonctionne avec de nombreux formats.
Vous pouvez spécifier une date précise, comme (2008-01-15).
Vous pouvez spécifier une date relative, comme (Il y a 2 ans, 1 jour et 3 minutes, 2 years 1 day 3 minutes ago).
Vous pouvez également filtrer la liste pour sélectionner les commits correspondant à certains critères de recherche.
L'option (--author) vous permet de filtrer sur un auteur spécifique.
L'option (--grep) vous permet de rechercher des mots-clés dans les messages de commit.
On note que :
On note que :
Si vous souhaitez spécifier à la fois les options (--author) et (--grep), vous devez ajouter l'option (--all-match), sinon la commande recherchera les commits utilisant l'une ou l'autre.
... $ git log --since=2.weeks ...
On exécute la commande (git, log, S) pour afficher les commits ayant ajouté ou supprimé la chaîne (function_name) dans le code.
On note que :
On note que :
L'option (-S) permet d'afficher uniquement les commits ayant introduit une modification dans le code ayant ajouté ou supprimé la chaîne (function_name).
On note que :
On note que :
Cette commande permet, par exemple, de trouver le dernier commit ayant ajouté ou supprimé une référence à une fonction spécifique.
On note que :
On note que :
La dernière option vraiment utile à passer à la commande (git, log) comme filtre est un chemin de fichier (FILE).
En spécifiant un répertoire ou un nom de fichier, vous pouvez limiter la sortie du journal aux commits ayant introduit une modification dans ces fichiers.
Il s'agit toujours de la dernière option et elle est généralement précédée de deux tirets (--) pour séparer les chemins des options.
... $ git log --Sfunction_name ...
On jette un coup d'oeil sur le tableau suivant pour résumer quelques options pour limiter la sortie de la commande (git, log).
...
================================================
Option-----------------Description
=============================================
-N---------------------Afficher uniquement les N derniers commits
--since, --after-------Limiter les commits à ceux effectués
après la date spécifiée
--until, --before------Limiter les commits à ceux effectués
avant la date spécifiée
--author---------------Afficher uniquement les commits dont l'entrée
auteur correspond à la chaîne spécifiée
--committer------------Afficher uniquement les commits dont l'entrée
committer correspond à la chaîne spécifiée
--grep-----------------Afficher uniquement les commits dont le message de
commit contient la chaîne
-S---------------------Afficher uniquement les commits qui ajoutent ou
suppriment du code correspondant à la chaîne
================================================
...On exécute la commande (git, log, pretty, author, since, before, no-merges) pour afficher les commits modifiant les fichiers de test (t/), validés par (Junio C Hamano), n'étant pas des fusions, au mois d'octobre 2008.
On note que :
On note que :
L'auteur (gitster, Junio C Hamano ) correspond à (Junio C Hamano).
Les dates depuis le (01 octobre 2008) et avant le (01 novembre 2008) correspondent à la date (au mois d'octobre 2008).
Le répertoire (t/) correspond au répertoire des fichiers de test.
L'option (--no-merges) correspond à un commit qui n'a pas plusieurs parents ; c'est-à-dire qui n'est pas un point de fusion.
On constate que :
On constate que :
Parmi les près de 40 000 commits dans l'historique du code source de Git, cette commande affiche les 6 qui correspondent à ces critères.
...
$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
--before="2008-11-01" --no-merges -- t/
...
5610e3b - Fix testcase failure when extended attributes are in use
acd3b9e - Enhance hold_lock_file_for_{update,append}() API
f563754 - demonstrate breakage of detached checkout with symbolic link HEAD
d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths
51a94af - Fix "checkout --track -b newbranch" on detached HEAD
b0ad11e - pull: allow "git pull origin $something:$current_branch" into
an unborn branch
...Annulation du dernier commit
On exécute la commande (git, commit, amend) pour annuler et remplacer le dernier commit.
On note que :
On note que :
Cette commande utilise votre zone d'indexation pour le commit de remplacement.
Si vous n'avez apporté aucune modification depuis votre dernier commit (par exemple, si vous exécutez cette commande immédiatement après le commit précédent), votre instantané sera identique, et seul votre message de commit sera modifié.
Le même éditeur de messages de commit se lance, mais il contient déjà le message de votre commit précédent.
Vous pouvez modifier le message comme d'habitude, mais cela écrase votre commit précédent.
... $ git commit --amend ...
On exécute la commande (git, commit, m) pour valider les modifications avec le message (initial commit).
On exécute la commande (git, add) pour indexer le fichier (forgotten_file).
On exécute la commande (git, commit, amend) pour annuler et remplacer le dernier commit.
On note que :
On note que :
Vous obtenez un seul commit.
Le second commit remplace les résultats du premier.
... $ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend ...
Suppression d'un fichier de la zone d'indexation
On exécute la commande (git, add, .) pour indexer tous les fichiers modifiés.
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On note que :
On note que :
La commande (git, add, .) prend en compte les nouveaux fichiers lors de l'indexation.
La commande (git, add, .) ne prend pas en compte les fichiers ignorés dans le fichier (.gitignore) lors de l'indexation. Ce qui est tout à fait correct.
La commande (git, add, .) ne prend pas en compte les fichiers supprimés sans la commande (git, rm) lors de l'indexation dans la version (Git, 1.x).
La commande (git, add, .) prend en compte les fichiers supprimés sans la commande (git, rm) lors de l'indexation dans la version (Git, 2.x).
On constate que :
On constate que :
Le fichier (README.md) est renommé et indexé.
Le fichier (benchmarks.rb) est modifié et indexé.
On note que :
On note que :
La commande (git, status) vous rappelle comment annuler l'indexation d'un fichier juste en dessous du texte (Changes to be committed, Modifications à valider).
Il est indiqué d'utiliser la commande (git, reset, HEAD, FILE) pour annuler l'indexation.
...
$ git add .
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
modified: benchmarks.rb
...On exécute la commande (git, reset, HEAD) pour annuler l'indexation du fichier (benchmarks.rb).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On suppose que :
On suppose que :
Vous aviez saisi accidentellement la commande (git, add, .) précédemment et indexé tous les deux fichiers.
Vous souhaitiez valider les fichiers séparément pour des raisons d'ergonomie.
On constate que :
On constate que :
Le fichier (README.md) est renommé et indexé.
Le fichier (benchmarks.md) est modifié et non indexé.
On note que :
On note que :
Le fichier (README.md) est présent dans la zone d'indexation ; il sera pris en compte lors du prochain commit.
Tandis que, le fichier (benchmarks.md) est retiré de la zone d'indexation ; il ne sera pas pris en compte lors du prochain commit.
On note que :
On note que :
La commande (git, reset) peut être dangereuse lorsqu'elle est appelée avec l'option (--hard) ; elle affecte la zone d'indexation et le répertoire de travail.
La commande (git, reset) sans option n'est pas dangereux ; elle n'affecte que la zone d'indexation.
...
$ git reset HEAD benchmarks.rb
...
Unstaged changes after reset:
M benchmarks.rb
...
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: benchmarks.rb
...On jette un coup d'oeil sur une partie de la sortie de la commande (git, status) précédente pour comprendre comment annuler les modifications apportées à un fichier non indexé.
On suppose que :
On suppose que :
Vous ne souhaitez pas conserver les modifications apportées au fichier (benchmarks.rb).
On note que :
On note que :
La commande (git, status) vous indique également comment procéder en dessous du texte (Changes not staged for commit, Modifications non indexées pour la validation).
Il est indiqué d'utiliser la commande (git, checkout, FILE) pour annuler les modifications non indexés.
...
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: benchmarks.rb
...Suppression des modifications locales
On exécute la commande (git, checkout) pour annuler les modifications non indexées du fichier (benchmarks.rb).
On exécute la commande (git, status) pour afficher l'état du répertoire de travail.
On constate que :
On constate que :
Le fichier (benchmarks.rb) n'apparaît plus dans la sortie de la commande (git, status).
On note que :
On note que :
La commande (git, checkout, FILE) est dangereuse ; toutes les modifications apportées à ce fichier sont perdues ; vous avez simplement copié un autre fichier par-dessus ; n'utilisez jamais cette commande, sauf si vous êtes absolument certain de ne pas vouloir conserver ce fichier.
On note que :
On note que :
Si vous souhaitez conserver les modifications apportées à ce fichier, mais que vous devez tout de même vous en débarrasser pour l'instant, vous pouvez utiliser le stockage et la création de branches qui sont généralement de meilleures méthodes.
On note que :
On note que :
Tout ce qui est validé dans Git peut presque toujours être récupéré. Même les commits qui se trouvaient sur des branches supprimées ou écrasés par la commande (git, commit, amend) peuvent être récupérés.
Cependant, tout ce que vous perdez et qui n'a jamais été validé est susceptible de ne jamais être revu.
...
$ git checkout -- benchmarks.rb
$ git status
...
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
...Gestion des serveurs distants
On exécute la commande (git, clone) pour cloner le dépôt (ticgit).
On exécute la commande (cd) pour se déplacer dans le dépôt (ticgit).
On exécute la commande (git, remote) pour afficher les noms des serveurs distants.
On note que :
On note que :
La commande (git, remote) répertorie les noms de chaque serveur distant.
Si vous avez cloné votre dépôt, vous devriez au moins voir (origin), le nom par défaut que Git attribue au serveur du dépôt cloné.
On constate que :
On constate que :
Le nom (origin) apparait suite à l'exécution de la commande (git, remote).
... $ git clone https://github.com/schacon/ticgit ... Cloning into 'ticgit'... remote: Reusing existing pack: 1857, done. remote: Total 1857 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done. Resolving deltas: 100% (772/772), done. Checking connectivity... done. ... $ cd ticgit $ git remote ... origin ...
On exécute la commande (git, remote, v) pour afficher les noms et les URLs des serveurs distants.
On constate que :
On constate que :
Le nom (origin) est utilisé pour récupérer (fetch) des données du dépôt (ticgit, https://github.com/schacon/ticgit).
Le nom (origin) est utilisé pour pousser (push) des données sur le dépôt (ticgit, https://github.com/schacon/ticgit).
... $ git remote -v ... Origin https://github.com/schacon/ticgit (fetch) Origin https://github.com/schacon/ticgit (push) ...
On exécute la commande (cd) pour se déplacer dans le dépôt (grit).
On exécute la commande (git, remote, v) pour afficher les noms et les URLs des serveurs distants.
On note que :
On note que :
Si vous possédez plusieurs URLs enregistrées, la commande (git, remote, v) les répertorie toutes.
Cela signifie que :
Cela signifie que :
Nous pouvons facilement récupérer les contributions de n'importe lequel de ces utilisateurs.
Nous pouvons également être autorisés à envoyer des contributions à un ou plusieurs d'entre eux.
On constate que :
On constate que :
Les utilisateurs distants utilisent divers protocoles (https, git).
... $ cd grit $ git remote -v ... bakkdoor https://github.com/bakkdoor/grit (fetch) bakkdoor https://github.com/bakkdoor/grit (push) cho45 https://github.com/cho45/grit (fetch) cho45 https://github.com/cho45/grit (push) defunkt https://github.com/defunkt/grit (fetch) defunkt https://github.com/defunkt/grit (push) koke git://github.com/koke/grit.git (fetch) koke git://github.com/koke/grit.git (push) origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ...
On exécute la commande (git, remote) pour afficher les noms des serveurs distants.
On exécute la commande (git, remote, add) pour configurer le nom (pb) associé au dépôt (ticgit, https://github.com/paulboone/ticgit).
On exécute la commande (git, remote, v) pour afficher les noms des serveurs distants.
On constate que :
On constate que :
Le nom (origin) pointe vers le dépôt (ticgit, https://github.com/schacon/ticgit).
Le nom (pb) pointe vers le dépôt (ticgit, https://github.com/paulboone/ticgit).
On note que :
On note que :
Vous pouvez désormais utiliser la chaîne (pb) en ligne de commande à la place de l'URL complète (https://github.com/paulboone/ticgit).
... $ git remote ... origin ... $ git remote add pb https://github.com/paulboone/ticgit $ git remote -v ... origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ...
On exécute la commande (git, fetch) pour récupérer toutes les informations dont Paul dispose mais qui ne sont pas encore dans votre répertoire de travail.
On note que :
On note que :
La branche principale de Paul est désormais accessible localement sous le nom (pb/master).
Vous pouvez la fusionner avec l'une de vos branches ou extraire une branche locale à ce stade pour l'inspecter.
... $ git fetch pb ... remote: Counting objects: 43, done. remote: Compressing objects: 100% (36/36), done. remote: Total 43 (delta 10), reused 31 (delta 5) Unpacking objects: 100% (43/43), done. From https://github.com/paulboone/ticgit * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit ...
On jette un coup d'oeil sur la commande (git, fetch) suivante pour comprendre sa structure.
On note que :
On note que :
La commande (git, fetch) permet de récupérer des données à partir d'un dépôt distant (REMOTE_NAME).
On note que :
On note que :
Vous devriez alors disposer de références à toutes les branches de ce projet distant (REMOTE_NAME), que vous pouvez fusionner ou inspecter à tout moment.
On note que :
On note que :
Si vous clonez un dépôt (REMOTE_URL), la commande ajoute automatiquement ce dépôt distant sous le nom « origin ».
Ainsi, la commande (git, fetch, origin) récupère tout nouveau travail envoyé sur ce serveur depuis son clonage (ou sa dernière récupération).
On note que :
On note que :
La commande (git, fetch) récupère les données vers votre dépôt local.
Elle ne les fusionne pas automatiquement avec votre travail ni ne modifie celui sur lequel vous travaillez actuellement.
Vous devez les fusionner manuellement avec votre travail lorsque vous êtes prêt.
On note que :
On note que :
Si vous avez configuré une branche locale pour suivre une branche distante, vous pouvez utiliser la commande (git, pull) pour récupérer automatiquement puis fusionner une branche distante avec votre branche actuelle.
Ce processus peut être plus simple et plus confortable pour vous.
Par défaut, la commande (git, clone) configure automatiquement votre branche (master) locale pour suivre la branche (master) distante, ou le nom de la branche par défaut sur le serveur cloné.
L'exécution de (git, pull) récupère généralement les données du serveur cloné et tente automatiquement de les intégrer au code en cours.
... $ git fetch REMOTE_NAME ...
On exécute la commande (git, push) pour pousser les commits sur la branche (master) du dépôt (origin, ticgit).
On note que :
On note que :
Le clonage d'un dépôt configure généralement les deux noms (master, branche principale) et (origin, serveur du dépôt cloné).
On note que :
On note que :
La commande (git, push) ne fonctionne que si vous avez cloné depuis un serveur auquel vous avez accès en écriture et si personne n'a effectué de commande (git, push) entre-temps.
Si vous et une autre personne clonez simultanément et que cette dernière effectue une commande (git, push) avant, puis que vous effectuez une commande (git, push) après, votre commande (git, push) sera rejetée à juste titre.
Vous devrez d'abord extraire son travail (1) et l'intégrer au vôtre (2) avant de pouvoir effectuer une commande (git, push, 3).
... $ git push origin master ...
On exécute la commande (git, remote, show) pour afficher les informations sur les branches du dépôt (origin, ticgit).
On note que :
On note que :
La commande (git, remote, show) permet d'afficher l'URL du dépôt distant (ticgit) ainsi que les informations sur les branches de suivi.
On constate que :
On constate que :
La commande (git, remote, show) vous indique que si vous êtes sur la branche (master, local) et que vous exécutez la commande (git, pull), la fusion sera automatique dans la branche (master, remote) du dépôt distant après avoir récupéré toutes les références distantes.
La commande (git, remote, show) affiche aussi toutes les références distantes extraites (master, dev-branch).
On note que :
On note que :
C'est un exemple simple que vous êtes susceptible de rencontrer.
Cependant, si vous utilisez Git plus fréquemment, vous obtiendrez beaucoup plus d'informations grâce à la commande (git, remote, show).
...
$ git remote show origin
...
* remote origin
Fetch URL: https://github.com/schacon/ticgit
Push URL: https://github.com/schacon/ticgit
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
...On exécute la commande (git, remote, show) pour afficher les informations sur les branches du dépôt (origin, complex-project).
On constate que :
On constate que :
La commande (git, remote, show) indique la branche vers laquelle les modifications sont automatiquement poussées lorsque vous exécutez la commande (git, push) sur certaines branches (dev-branch, markdown-strip, master).
La commande (git, remote, show) indique aussi les branches distantes du serveur que vous n'avez pas encore (issue-43 new, issue-45 new), celles qui ont été supprimées du serveur (issue-11) et celles qui sont automatiquement fusionnées (dev-branch, master) lorsque vous exécutez la commande (git, pull).
...
$ git remote show origin
...
* remote origin
URL: https://github.com/my-org/complex-project
Fetch URL: https://github.com/my-org/complex-project
Push URL: https://github.com/my-org/complex-project
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
markdown-strip tracked
issue-43 new (next fetch will store in remotes/origin)
issue-45 new (next fetch will store in remotes/origin)
refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
dev-branch merges with remote dev-branch
master merges with remote master
Local refs configured for 'git push':
dev-branch pushes to dev-branch (up to date)
markdown-strip pushes to markdown-strip (up to date)
master pushes to master (up to date)
...On exécute la commande (git, remote, rename) pour renommer le nom de serveur de (pb, ticgit) à (paul, ticgit).
On exécute la commande (git, remote) pour afficher les noms des serveurs distants.
On constate que :
On constate que :
Le nom de serveur (pb) est remplacé par (paul).
On note que :
On note que :
La commande (git, remote, rename) modifie également les noms de vos branches distantes ; ce qui était auparavant référencé dans (pb/master) est désormais dans (paul/master) ; ce qui est tout à fait correct.
... $ git remote rename pb paul $ git remote ... origin paul ...
On exécute la commande (git, remote, rm) pour supprimer le serveur distant (paul, ticgit) du répertoire de travail.
On note que :
On note que :
La commande (git, remote, rm) peut être exécutée pour l'une des raisons suivantes (déplacement du serveur, désactivation d'un miroir particulier, ou encore l'arrêt d'un contributeur).
... $ git remote rm paul $ git remote ... origin ...
Gestion des tags
On exécute la commande (git, tag) pour afficher la liste des tags (balises).
On note que :
On note que :
La commande (git, tag) liste les tags par ordre alphabétique.
L'ordre dans lequel les tags apparaissent n'a pas de réelle importance.
... $ git tag ... v0.1 v1.3 ...
On exécute la commande (git, tag, l) pour rechercher les tags (v1.8.5*).
On note que :
On note que :
La commande (git, tag, l) permet de rechercher des tags selon un modèle particulier.
On constate que :
Les tags affichés commencent par (v1.8.5).
On constate que :
Les tags affichés commencent par (v1.8.5).
... $ git tag -l 'v1.8.5*' ... v1.8.5 v1.8.5-rc0 v1.8.5-rc1 v1.8.5-rc2 v1.8.5-rc3 v1.8.5.1 v1.8.5.2 v1.8.5.3 v1.8.5.4 v1.8.5.5 ...
On exécute la commande (git, tag, a, m) pour créer le tag annoté (v1.4) avec l'annotation (my version 1.4).
On exécute la commande (git, tag) pour afficher la liste des tags.
On note que :
On note que :
Git utilise deux principaux types de balises : les tags légers et les tags annotés.
Un tag léger ressemble beaucoup à une branche immuable : c'est juste un pointeur vers un commit spécifique.
Les tags annotés, quant à eux, sont stockées sous forme d'objets complets dans la base de données Git. Ils sont soumis à une somme de contrôle ; ils contiennent le nom, l'adresse email et la date du tagueur ; ils comportent un message d'annotation ; et peuvent être signées et vérifiées avec GNU Privacy Guard (GPG).
Il est généralement recommandé de créer des tags annotées pour disposer de toutes ces informations ; mais si vous souhaitez un tag temporaire ou si, pour une raison quelconque, vous ne souhaitez pas conserver les autres informations, des tags légers sont également disponibles.
... $ git tag -a v1.4 -m 'my version 1.4' $ git tag ... v0.1 v1.3 v1.4 ...
On exécute la commande (git, show) pour afficher les informations sur le tag (v1.4).
On constate que :
On constate que :
La commande (git, show) affiche les informations du tagueur (Ben Straub ), la date à laquelle le commit a été tagué (Sat May 3 20:19:12 2014, Sam. 3 mai 2014 20:19:12) et le message d'annotation (my version 1.4).
La commande (git, show) affiche aussi les informations du commit (ca82a6dff817ec66f44342007202690a93763949), l'auteur du commit (Scott Chacon schacon@gee-mail.com), la date du commit (Mon Mar 17 21:52:11 2008, Lun. 17 mars 2008 21:52:11) et le message de commit (changed the verison number).
... $ git show v1.4 ... tag v1.4 Tagger: Ben Straub <ben@straub.cc> Date: Sat May 3 20:19:12 2014 -0700 my version 1.4 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the verison number ...
On exécute la commande (git, tag) pour créer le tag léger (v1.4-1w).
On exécute la commande (git, tag) pour afficher la liste des tags.
On note que :
On note que :
Un tag léger est en fait de la somme de contrôle du commit stockée dans un fichier ; aucune autre information n'est conservée.
... $ git tag v1.4-lw $ git tag ... v0.1 v1.3 v1.4 v1.4-lw v1.5 ...
On exécute la commande (git, show) pour afficher les informations sur le tag (v1.4-lw).
On constate que :
On constate que :
La commande (git, show) n'affiche aucune information supplémentaire sur le tag léger (v1.4-lw). Elle affiche simplement les informations du commit.
... $ git show v1.4-lw ... commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the verison number ...
On exécute la commande (git, log, pretty, oneline) pour afficher l'historique des commits sur une seule ligne.
On note que :
On note que :
Vous pouvez aussi taguer les commits après les avoir dépassés.
... $ git log --pretty=oneline ... 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ...
On exécute la commande (git, tag, a) pour créer le tag (v1.2) à partir du commit (9fceb02, updated rakefile).
On note que :
On note que :
Vous pouvez spécifiez la somme de contrôle SHA-1 du commit (9fceb02d0ae598e95dc970b74767f19372d61af8, updated rakefile) ou une partie de celle-ci (9fceb02, updated rakefile) à la fin de la commande.
... $ git tag -a v1.2 9fceb02 ...
On exécute la commande (git, tag) pour afficher la liste des tags.
On constate que :
On constate que :
Le tag (v1.2) est créé.
... $ git tag ... v0.1 v1.2 v1.3 v1.4 v1.4-lw v1.5 ...
On exécute la commande (git, show) pour afficher les informations sur le tag (v1.2).
On constate que :
On constate que :
La commande (git, show) affiche les informations du tag (v1.2) avec le nom du tagueur (Scott Chacon ), la date à laquelle le commit a été tagué (Mon Feb 9 15:32:16 2009, Lun. 9 févr. 2009 15:32:16) et le message d'annotation (version 1.2).
La commande (git, show) affiche aussi les informations du commit (9fceb02d0ae598e95dc970b74767f19372d61af8), l'auteur du commit (Magnus Chacon ), la date du commit (Sun Apr 27 20:43:35 2008, Dim. 27 avr. 2008 20:43:35) et le message de commit (updated rakefile).
... $ git show v1.2 ... tag v1.2 Tagger: Scott Chacon <schacon@gee-mail.com> Date: Mon Feb 9 15:32:16 2009 -0800 version 1.2 commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon <mchacon@gee-mail.com> Date: Sun Apr 27 20:43:35 2008 -0700 updated rakefile ...
On exécute la commande (git, push) pour pousser le tag (v1.5) sur le serveur distant (origin).
On note que :
On note que :
La commande (git, push) ne transfère pas les tags vers des serveurs distants.
Vous devrez pousser les tags vers un serveur distant après les avoir créées.
Ce processus est similaire au partage de branches distantes.
... $ git push origin v1.5 ... Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ...
On exécute la commande (git, push, tags) pour transférer tous les tags manquants vers le serveur distant (origin).
On constate que :
On constate que :
Les tags (v1.4, v1.4-1w) ont été transférés sur le serveur distant (origin).
On note que :
On note que :
Désormais, lorsque quelqu'un d'autre clone ou extrait des données de votre dépôt, il obtiendra également tous vos tags.
... $ git push origin --tags ... Counting objects: 1, done. Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw ...
Gestion des alias
On exécute la commande (git, config, global, alias) pour créer l'alias (co) avec la valeur (checkout).
On exécute la commande (git, config, global, alias) pour créer l'alias (br) avec la valeur (branch).
On exécute la commande (git, config, global, alias) pour créer l'alias (ci) avec la valeur (commit).
On exécute la commande (git, config, global, alias) pour créer l'alias (st) avec la valeur (status).
On note que :
On note que :
Les alias évitent de saisir l'intégralité de chaque commande Git. Ils permettent de créer des raccourcis de commandes.
On note que :
On note que :
Au lieu de saisir la commande (git, commit), il vous suffit de saisir l'alias (git, ci).
À mesure que vous utiliserez Git, vous utiliserez probablement d'autres commandes fréquemment ; n'hésitez pas à créer de nouveaux alias.
On note que :
On note que :
Cette technique peut également s'avérer très utile pour créer des commandes qui, selon vous, devraient exister.
Par exemple, pour corriger le problème d'ergonomie rencontré lors de la désindexation d'un fichier, vous pouvez ajouter votre propre alias de désindexation à Git.
... $ git config --global alias.co checkout $ git config --global alias.br branch $ git config --global alias.ci commit $ git config --global alias.st status ...
On exécute la commande (git, config, global, alias) pour créer l'alias (unstage) avec la valeur (reset HEAD --).
On note que :
On note que :
La commande (git, unstage) sera désormais présente dans notre environnement Git et nous permettra de supprimer un fichier de la zone d'indexation afin de le valider à partir d'un autre commit pour des raisons d'ergonomie.
... $ git config --global alias.unstage 'reset HEAD --' ...
On exécute la commande (git, unstage) pour supprimer le fichier (fileA) de la zone d'indexation.
On exécute la commande (git, reset, HEAD) pour supprimer le fichier (fileA) de la zone d'indexation.
On note que :
On note que :
Ces deux commandes sont équivalentes ; elles font exactement la même chose.
On note que :
On note que :
La commande (git, unstage) semble être beaucoup plus claire ; car l'intention est indiquée dans le nom de la commande (unstage, désindexation).
... $ git unstage fileA $ git reset HEAD fileA ...
On exécute la commande (git, config, global, alias) pour créer l'alias (last) avec la valeur (log -1 HEAD).
On note que :
On note que :
La commande (git, last) sera désormais présente dans notre environnement Git et nous permettra d'afficher le dernier commit.
... $ git config --global alias.last 'log -1 HEAD' ...
On exécute la commande (git, last) pour afficher le dernier commit.
On constate que :
On constate que :
Le dernier commit est affiché.
On constate que :
On constate que :
Git remplace simplement la nouvelle commande par l'alias que vous lui avez attribué.
... $ git last ... commit 66938dae3329c7aebe598c2246a8e6af90d04646 Author: Josh Goebel <dreamer3@example.com> Date: Tue Aug 26 19:48:51 2008 +0800 test for current head Signed-off-by: Scott Chacon <schacon@example.com> ...
On exécute la commande (git, config, global, alias) pour créer l'alias (visual) avec la valeur (!gitk).
On note que :
On note que :
Si vous pouvez souhaiter exécuter une commande externe plutôt qu'une sous-commande Git, commencez la commande par un caractère (!). Ceci est utile si vous souhaitez développer vos propres outils fonctionnant avec un dépôt Git.
On note que :
On note que :
La commande (git, visual) sera désormais présente dans notre environnement Git et nous permettra de lancer l'outil (gitk) depuis notre shell.
... $ git config --global alias.visual "!gitk" ...