Documentation du Dr FRAPPE

Ce wiki regroupe les résultats de mes expériences en informatique accumulés au cours de mes recherches sur le net.

Dans la mesure du possible, j'ai cité mes sources ; il en manque certainement… :-)

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
logiciel:programmation:git:10_commandes [2021/02/17 10:08] – ↷ Page déplacée de fr:logiciel:programmation:git:10_commandes à logiciel:programmation:git:10_commandes adminlogiciel:programmation:git:10commandes:start [2022/08/13 22:15] (Version actuelle) – modification externe 127.0.0.1
Ligne 1: Ligne 1:
 ====== GIT : Utilisation simplifiée en dix commandes ====== ====== GIT : Utilisation simplifiée en dix commandes ======
  
-====== Webographie ======+===== Webographie =====
  
   - [[http://blog.xkoder.com/2008/08/13/git-tutorial-starting-with-git-using-just-10-commands/]]   - [[http://blog.xkoder.com/2008/08/13/git-tutorial-starting-with-git-using-just-10-commands/]]
  
-===== Pré-requis =====+==== Pré-requis ====
  
   - un ordinateur de préférence sous Linux. (Nous ne traitons pas de Windows ici   - un ordinateur de préférence sous Linux. (Nous ne traitons pas de Windows ici
Ligne 11: Ligne 11:
   - un projet en développement, dans n'importe quel langage (C, C + +, D, Python, Perl, HTML, JavaScript, etc.)   - un projet en développement, dans n'importe quel langage (C, C + +, D, Python, Perl, HTML, JavaScript, etc.)
  
-===== Allons-y ! =====+==== Allons-y ! ====
  
-==== "git init" : initialisation d'une base git vide ====+=== "git init" : initialisation d'une base git vide ===
  
 Avant de commencer à utiliser la puissance de git, il faut créer un dépôt git vide et dire quels sont les fichiers à suivre. Avant de commencer à utiliser la puissance de git, il faut créer un dépôt git vide et dire quels sont les fichiers à suivre.
Ligne 25: Ligne 25:
 Ensuite, lancer les 2 prochaines commandes présentées ci-dessous. Ensuite, lancer les 2 prochaines commandes présentées ci-dessous.
  
-==== "git add" : Ajout de fichiers au référentiel git ====+=== "git add" : Ajout de fichiers au référentiel git ===
  
 L'étape suivante consiste à ajouter des fichiers au dépôt git, c'est-à-dire signales à git les fichiers dont on veut garder la trace. Exécutez la commande suivante à partir du dossier de base : L'étape suivante consiste à ajouter des fichiers au dépôt git, c'est-à-dire signales à git les fichiers dont on veut garder la trace. Exécutez la commande suivante à partir du dossier de base :
Ligne 33: Ligne 33:
 Cela va ajouter au dépôt git, de manière récursive, tous les fichiers du dossier actuel et de ses sous-dossiers. Cela va ajouter au dépôt git, de manière récursive, tous les fichiers du dossier actuel et de ses sous-dossiers.
  
-==== "git commit" : La commande commit ====+=== "git commit" : La commande commit ===
  
 C'est une commande qu'on va utiliser souvent. C'est une commande qu'on va utiliser souvent.
Ligne 55: Ligne 55:
 Maintenant, nous allons avancer et apprendre quelques commandes de plus. Maintenant, nous allons avancer et apprendre quelques commandes de plus.
  
-==== "git log" : Affichage du journal de validation. ====+=== "git log" : Affichage du journal de validation. ===
  
 on peut relire tous les commits faits jusqu'à présent avec la commande suivante : on peut relire tous les commits faits jusqu'à présent avec la commande suivante :
Ligne 70: Ligne 70:
 De tous ceux-ci, le premier élément, l'identificateur unique, est le plus important. Ce hachage sera utilisé avec certaines des commandes suivantes, et est utilisé avec une pléthore d'autres commandes git De tous ceux-ci, le premier élément, l'identificateur unique, est le plus important. Ce hachage sera utilisé avec certaines des commandes suivantes, et est utilisé avec une pléthore d'autres commandes git
  
-==== "git status" : Vérification de l'état actuel ====+=== "git status" : Vérification de l'état actuel ===
  
 Lors du codage, on peut voir toutes les modifications avant de se résoudre à les stocker dans le dépôt git. C'est ce que permet cette commande : Lors du codage, on peut voir toutes les modifications avant de se résoudre à les stocker dans le dépôt git. C'est ce que permet cette commande :
Ligne 78: Ligne 78:
 La commande ci-dessus liste tous les fichiers qui ont changé depuis la dernière validation. La commande ci-dessus liste tous les fichiers qui ont changé depuis la dernière validation.
  
-==== "git diff" : Trouver les différences entre les commit ====+=== "git diff" : Trouver les différences entre les commit ===
  
 Outre la seule visualisation de fichiers qui ont changé, on peut vouloir visualiser les différences dans le code source. C'est ce que fait la commande : Outre la seule visualisation de fichiers qui ont changé, on peut vouloir visualiser les différences dans le code source. C'est ce que fait la commande :
Ligne 98: Ligne 98:
 Cette commande va afficher les différences entre les deux commits identifiés par commit_hash_1 et commit_hash_2. Cette commande va afficher les différences entre les deux commits identifiés par commit_hash_1 et commit_hash_2.
  
-==== "git branch" : Créer des branches ====+=== "git branch" : Créer des branches ===
  
 Les branches sont faciles à utiliser et très utiles. Les branches sont faciles à utiliser et très utiles.
Ligne 110: Ligne 110:
   * À un moment donné, on ne peut être assis que sur une seule branche. C'est-à-dire que c'est le code source de la branche en cours qui est en vigueur, celui auquel on veut faire des changements.   * À un moment donné, on ne peut être assis que sur une seule branche. C'est-à-dire que c'est le code source de la branche en cours qui est en vigueur, celui auquel on veut faire des changements.
  
-=== Pourquoi utiliser les branches ? ===+== Pourquoi utiliser les branches ? ==
  
 Soit un code source quasi-stable à distribuer prochainement. On envisage aussi d'y inclure une caractéristique importante, mais on craint de casser ce qui est fait et de retarder le plan de mise en service. Soit un code source quasi-stable à distribuer prochainement. On envisage aussi d'y inclure une caractéristique importante, mais on craint de casser ce qui est fait et de retarder le plan de mise en service.
Ligne 122: Ligne 122:
 Revenons aux commandes. Pour créer une branche, Lancer la commande suivante : Revenons aux commandes. Pour créer une branche, Lancer la commande suivante :
  
-=== Création d'une branche ===+== Création d'une branche ==
  
   $ Git branch branch_name   $ Git branch branch_name
Ligne 130: Ligne 130:
   $ Git branch experimental_feature   $ Git branch experimental_feature
  
-=== Branchement dans une branche ou "Je veux plus de branches" ===+== Branchement dans une branche ou "Je veux plus de branches" ==
  
 Dans une branche, on peut créer autant de branches que l'on veut, en créant éventuellement un arbre très dense. Dans une branche, on peut créer autant de branches que l'on veut, en créant éventuellement un arbre très dense.
Ligne 136: Ligne 136:
 Il suffit de s'y placer (checkout de cette branche, voir ci-dessous commande 8) et d'émettre la commande de création de branche. Il suffit de s'y placer (checkout de cette branche, voir ci-dessous commande 8) et d'émettre la commande de création de branche.
  
-==== "git checkout" : Déplacer une branche et lister toutes les branches ====+=== "git checkout" : Déplacer une branche et lister toutes les branches ===
  
 Une fois créée une branche, s'y déplacer avec la commande ci-dessous. Une fois créée une branche, s'y déplacer avec la commande ci-dessous.
Ligne 152: Ligne 152:
   $ Git checkout master   $ Git checkout master
  
-=== Liste de toutes les branches ===+== Liste de toutes les branches ==
  
 La commande suivante affiche toutes les branches disponibles dans le référentiel actuel. La commande suivante affiche toutes les branches disponibles dans le référentiel actuel.
Ligne 158: Ligne 158:
   $ Git branch   $ Git branch
  
-==== "git merge" : Fusionner deux branches ====+=== "git merge" : Fusionner deux branches ===
  
 Se déplacer (checkout) vers la branche à laquelle on souhaite appliquer la fusion et exécuter la commande suivante. Se déplacer (checkout) vers la branche à laquelle on souhaite appliquer la fusion et exécuter la commande suivante.
Ligne 173: Ligne 173:
 Git signale tous les conflits qu'il ne peut pas résoudre automatiquement (s'il en existe). On peut alors les résoudre manuellement. Git signale tous les conflits qu'il ne peut pas résoudre automatiquement (s'il en existe). On peut alors les résoudre manuellement.
  
-=== Suppression d'une branche ===+== Suppression d'une branche ==
  
 La fusion faite, on peut supprimer la branche expérimentale si on le veut, avec la commande : La fusion faite, on peut supprimer la branche expérimentale si on le veut, avec la commande :
Ligne 181: Ligne 181:
 Cette commande n'efface la branche que si elle entièrement fusionnée avec la branche HEAD courante. HEAD est la position actuelle dans la branche, le dernier commit. Cette commande n'efface la branche que si elle entièrement fusionnée avec la branche HEAD courante. HEAD est la position actuelle dans la branche, le dernier commit.
  
-==== "git rm" : Supprimer quelquechose dans le référentiel. ====+=== "git rm" : Supprimer quelquechose dans le référentiel. ===
  
 Lancer la commande suivante si on ne veut pas que git garde une trace d'un fichier ou un dossier (c'eest le contraire de la commande git-add). Le fichier reste sur le disque, dans le répertoire de travail. Lancer la commande suivante si on ne veut pas que git garde une trace d'un fichier ou un dossier (c'eest le contraire de la commande git-add). Le fichier reste sur le disque, dans le répertoire de travail.
Ligne 189: Ligne 189:
 La commande git-rm ne supprime les fichiers du référentiel que pour le HEAD, Les révisions ou commits précédents garderont le fichier. La commande git-rm ne supprime les fichiers du référentiel que pour le HEAD, Les révisions ou commits précédents garderont le fichier.
  
-===== Pour finir =====+==== Pour finir ====
  
 Encore des commandes utiles Encore des commandes utiles
  
-==== Une visionneuse graphique du référentiel ====+=== Une visionneuse graphique du référentiel ===
  
 Pour lancer une visionneuse graphique du référentiel, exécuter la commande suivante Pour lancer une visionneuse graphique du référentiel, exécuter la commande suivante
Ligne 199: Ligne 199:
   $ gitk   $ gitk
  
-==== Git - Interface utilisateur graphique ====+=== Git - Interface utilisateur graphique ===
  
 Pour ceux qui préfèrent une interface graphique, on peut installer une interface graphique pour git. Pour ubuntu : Pour ceux qui préfèrent une interface graphique, on peut installer une interface graphique pour git. Pour ubuntu :
Ligne 215: Ligne 215:
 fonctionne de base, sans avoir besoin de l'installer. fonctionne de base, sans avoir besoin de l'installer.
  
-====== Partie II du tutoriel - 10 autres commandes ======+===== Partie II du tutoriel - 10 autres commandes =====
  
-==== "git checkout" : Voyage dans le temps, déplacement aller-retour entre révisions ====+=== "git checkout" : Voyage dans le temps, déplacement aller-retour entre révisions ===
  
 Le but d'un système de contrôle de version est de conserver l'historique des révisions du votre code source... et de pouvoir visualiser à quoi ressemblait le code à tout moment de l'historique enregistré. Le but d'un système de contrôle de version est de conserver l'historique des révisions du votre code source... et de pouvoir visualiser à quoi ressemblait le code à tout moment de l'historique enregistré.
Ligne 223: Ligne 223:
 Git enregistre les révisions sous la forme de commits. Chaque commit est identifié pau un code de hachage unique. (Git utilise le hachage SHA1). On peut retrouver le numéro de hachage d'un commit en lançant la commande git-log (cf. la première partie). Le numéro de hachage est affiché dans le journal sous forme d'une chaîne hexadécimale sur la ligne qui commence par le mot "commit" dans le log. Git enregistre les révisions sous la forme de commits. Chaque commit est identifié pau un code de hachage unique. (Git utilise le hachage SHA1). On peut retrouver le numéro de hachage d'un commit en lançant la commande git-log (cf. la première partie). Le numéro de hachage est affiché dans le journal sous forme d'une chaîne hexadécimale sur la ligne qui commence par le mot "commit" dans le log.
  
-=== Déplacement vers un commit dans le passé ===+== Déplacement vers un commit dans le passé ==
  
 Pour revenir à un commit particulier dans le temps, on utilise la commande git-checkout (introduite dans la partie I pour se déplacer entre les branches). La syntaxe est similaire, mais au lieu du nom branche, on utilise le numéro de hachage du commit. Pour revenir à un commit particulier dans le temps, on utilise la commande git-checkout (introduite dans la partie I pour se déplacer entre les branches). La syntaxe est similaire, mais au lieu du nom branche, on utilise le numéro de hachage du commit.
Ligne 260: Ligne 260:
 L'extraction terminée, on peut afficher les fichiers pour voir leur état dans le passé. Pour modifier les fichiers et propager les changements dans le HEAD du master, cf. **Commande 6** plus loin. L'extraction terminée, on peut afficher les fichiers pour voir leur état dans le passé. Pour modifier les fichiers et propager les changements dans le HEAD du master, cf. **Commande 6** plus loin.
  
-=== Retour au présent ===+== Retour au présent ==
  
 Pour revenir au HEAD de master, qui est l'état actuel du code, taper la commande : Pour revenir au HEAD de master, qui est l'état actuel du code, taper la commande :
Ligne 268: Ligne 268:
 Comme déjà dit, ne pas oublier de valider les modifications par des commits ou des stashs. Comme déjà dit, ne pas oublier de valider les modifications par des commits ou des stashs.
  
-==== "git stash" : déplacement sans commit ====+=== "git stash" : déplacement sans commit ===
  
 C'est une commande très pratique. Elle permet de stocker les modifications en cours dans un cache temporaire. On peut ensuite les rappeler quand nécessaire. Cela réduit la nécessité de faire un commit à chaque fois que l'on veut se déplacer dans les branches ou les commits.  C'est une commande très pratique. Elle permet de stocker les modifications en cours dans un cache temporaire. On peut ensuite les rappeler quand nécessaire. Cela réduit la nécessité de faire un commit à chaque fois que l'on veut se déplacer dans les branches ou les commits. 
Ligne 282: Ligne 282:
   $ git stash pop   $ git stash pop
  
-=== Quand utiliser git-stash ===+== Quand utiliser git-stash ==
  
 Voici un scénario typique. Voici un scénario typique.
Ligne 303: Ligne 303:
   ...Continuer à travailler normalement...   ...Continuer à travailler normalement...
  
-=== Caches multiples ===+== Caches multiples ==
  
 On peut ranger plus d'une série de changements, si nécessaire, en exécutant la commande git-stash plusieurs fois. On peut ranger plus d'une série de changements, si nécessaire, en exécutant la commande git-stash plusieurs fois.
Ligne 309: Ligne 309:
 Quand on utilise la commande pop de git-stash, le dernier cache arrive en premier, un peu comme une pile. Quand on utilise la commande pop de git-stash, le dernier cache arrive en premier, un peu comme une pile.
  
-=== Voir les caches stockés ===+== Voir les caches stockés ==
  
 Pour afficher une liste des changements mis en cache, exécuter la commande suivante  Pour afficher une liste des changements mis en cache, exécuter la commande suivante 
Ligne 317: Ligne 317:
 On peut faire d'autres choses plus amusantes avec cette commande (cf. les pages de manuel pour git-stash). Mais pour une utilisation quotidienne normale, cela suffira.  On peut faire d'autres choses plus amusantes avec cette commande (cf. les pages de manuel pour git-stash). Mais pour une utilisation quotidienne normale, cela suffira. 
  
-==== "git diff" : quelques commutateurs pour mieux différencier. ====+=== "git diff" : quelques commutateurs pour mieux différencier. ===
    
 Cette commande a été présentée dans la première partie. Nous allons ici discuter de certaines options en ligne de commande, pour aider à trouver la bonne information.  Cette commande a été présentée dans la première partie. Nous allons ici discuter de certaines options en ligne de commande, pour aider à trouver la bonne information. 
  
-=== Trouver quels fichiers diffèrent (au lieu de ce qui diffère dans les fichiers) ===+== Trouver quels fichiers diffèrent (au lieu de ce qui diffère dans les fichiers) ==
  
 Voici la commande : Voici la commande :
Ligne 331: Ligne 331:
   $ git diff --name-status hash_1 hash_2   $ git diff --name-status hash_1 hash_2
  
-=== Utilisation du symbole HEAD ===+== Utilisation du symbole HEAD ==
  
 On peut utiliser le symbole HEAD pour voir les diffs, entre le HEAD courant et les révisions antérieures, comme suit: On peut utiliser le symbole HEAD pour voir les diffs, entre le HEAD courant et les révisions antérieures, comme suit:
Ligne 342: Ligne 342:
   commit_hash_just_before_HEAD   commit_hash_just_before_HEAD
  
-=== Qu'est-ce que le HEAD ? ===+== Qu'est-ce que le HEAD ? ==
  
 Comme discuté dans la première partie de ce tutoriel, HEAD se réfère au dernier commit sur la branche courante. Comme discuté dans la première partie de ce tutoriel, HEAD se réfère au dernier commit sur la branche courante.
Ligne 348: Ligne 348:
 On peut modifier le nombre après le tilde (~) pour trouver les différences entre le HEAD et ce nombre de commits avant le HEAD courant. Expérimenter et voir le résultat. Il n'y a aucun risque à essayer On peut modifier le nombre après le tilde (~) pour trouver les différences entre le HEAD et ce nombre de commits avant le HEAD courant. Expérimenter et voir le résultat. Il n'y a aucun risque à essayer
    
-==== "git add" revisité. ====+=== "git add" revisité. ===
  
 Dans la première partie de ce tutoriel, nous avons appris à faire que git suive un ou plusieurs fichiers en utilisant la commande << git add >>. Mais nous allons voir d'autres choses que peut faire git-add.  Dans la première partie de ce tutoriel, nous avons appris à faire que git suive un ou plusieurs fichiers en utilisant la commande << git add >>. Mais nous allons voir d'autres choses que peut faire git-add. 
Ligne 373: Ligne 373:
 On va voir pourquoi utiliser git-add de cette façon.</note>  On va voir pourquoi utiliser git-add de cette façon.</note> 
  
-=== Ne committer que certains fichiers sélectionnés ===+== Ne committer que certains fichiers sélectionnés ==
  
 Supposons que l'on travaille sur trois fichiers source. Deux fichiers sont corrects mais il reste du travail sur le troisième fichier. On peut committer seulement ces deux fichiers en lançant les commandes suivantes : Supposons que l'on travaille sur trois fichiers source. Deux fichiers sont corrects mais il reste du travail sur le troisième fichier. On peut committer seulement ces deux fichiers en lançant les commandes suivantes :
Ligne 402: Ligne 402:
 Tester aussi la commande git-reset (plus loin). Tester aussi la commande git-reset (plus loin).
  
-==== git-rm : un peu plus à savoir ====+=== git-rm : un peu plus à savoir ===
  
-=== Le commutateur –cached ===+== Le commutateur –cached ==
  
 Lorsque git-rm est utilisé avec ce commutateur, les fichiers sont retirés du dépôt git, mais ne sont pas supprimés du disque. Lorsque git-rm est utilisé avec ce commutateur, les fichiers sont retirés du dépôt git, mais ne sont pas supprimés du disque.
Ligne 414: Ligne 414:
 La commande ci-dessus va supprimer le fichier ou le dossier, mais ils resteront sur le disque. Si on fait la commande git-status, Le fichier sera affiché comme supprimé, ainsi que un-tracked (non suivi). La commande ci-dessus va supprimer le fichier ou le dossier, mais ils resteront sur le disque. Si on fait la commande git-status, Le fichier sera affiché comme supprimé, ainsi que un-tracked (non suivi).
  
-=== git-rm sans le commutateur –cached ===+== git-rm sans le commutateur –cached ==
  
 Utilisé sans le commutateur --cache, git-rm supprime le fichier du référentiel ainsi que sur le disque. Utilisé sans le commutateur --cache, git-rm supprime le fichier du référentiel ainsi que sur le disque.
Ligne 420: Ligne 420:
 Il faut committer les changements après un git-rm, avec ou sans le commutateur --cached. Il faut committer les changements après un git-rm, avec ou sans le commutateur --cached.
  
-=== Tout n'est pas perdu ! ===+== Tout n'est pas perdu ! ==
  
 Se rappeler que la suppression avec git-rm, validée, du ou des fichiers ne s'appliquent qu'à ce commit. Toutes les révisions précédentes ont encore le fichier ou le dossier supprimé. Si donc on fait une extraction des révisions précédentes, on peut retrouver les fichiers ou dossiers. Se rappeler que la suppression avec git-rm, validée, du ou des fichiers ne s'appliquent qu'à ce commit. Toutes les révisions précédentes ont encore le fichier ou le dossier supprimé. Si donc on fait une extraction des révisions précédentes, on peut retrouver les fichiers ou dossiers.
Ligne 426: Ligne 426:
 On ne peut pas modifier l'historique des commits (voir git-reset plus loin) car cela va à l'encontre de la fonctionnalité principale du système de contrôle de version qui est de conserver l'historique des changements dans le référentiel de code source. On ne peut pas modifier l'historique des commits (voir git-reset plus loin) car cela va à l'encontre de la fonctionnalité principale du système de contrôle de version qui est de conserver l'historique des changements dans le référentiel de code source.
  
-==== Gestion des branches ====+=== Gestion des branches ===
  
 Nous savons déjà comment créer, supprimer et nous déplacer entre les branches. Voici quelques commandes de plus pour vous gérer les dépôts. Nous savons déjà comment créer, supprimer et nous déplacer entre les branches. Voici quelques commandes de plus pour vous gérer les dépôts.
  
-=== Création d'une branche de certains anciens commits ===+== Création d'une branche de certains anciens commits ==
  
 Supposons que l'on veuille revenir à un commit particulier et créer une branche à partir de lui. On peut émettre les commandes suivantes : Supposons que l'on veuille revenir à un commit particulier et créer une branche à partir de lui. On peut émettre les commandes suivantes :
Ligne 452: Ligne 452:
 On peut utiliser l'interface graphique gitk pour faire visuellement un checkout des branches. On peut utiliser l'interface graphique gitk pour faire visuellement un checkout des branches.
  
-==== git reset ====+=== git reset ===
  
-=== Effacer les changements ===+== Effacer les changements ==
  
 Pour annuler des changements du code source dont on n'a pas besoin, la commande suivante efface toutes les modifications et revient au dernier état propre, à savoir le dernier commit (la dernière validation). Pour annuler des changements du code source dont on n'a pas besoin, la commande suivante efface toutes les modifications et revient au dernier état propre, à savoir le dernier commit (la dernière validation).
Ligne 466: Ligne 466:
 Cette commande peut être utile pour fusionner des branches des dépôts d'autres personnes en faisant ressortir les conflits, et si on veut restaurer le référentiel à un état propre. Avec cette commande, on retourne à l'état non fusionné. Cette commande peut être utile pour fusionner des branches des dépôts d'autres personnes en faisant ressortir les conflits, et si on veut restaurer le référentiel à un état propre. Avec cette commande, on retourne à l'état non fusionné.
  
-=== Effacer les fichiers marqués pour un commit ===+== Effacer les fichiers marqués pour un commit ==
  
 Pour ne plus faire de commit sur des fichiers que l'on a marqués, on peut lancer la commande suivante pour retirer leur marquage Pour ne plus faire de commit sur des fichiers que l'on a marqués, on peut lancer la commande suivante pour retirer leur marquage
Ligne 474: Ligne 474:
 Cette commande ne supprime le marquage que pour les commits, les changements restent. Cette commande ne supprime le marquage que pour les commits, les changements restent.
  
-=== Effacer les commits ===+== Effacer les commits ==
  
 Cette commande sert dans les rares cas où il faut vraiment modifier l'historique. Ou pour les rares cas où on a fait de mauvais commits. Cette commande sert dans les rares cas où il faut vraiment modifier l'historique. Ou pour les rares cas où on a fait de mauvais commits.
Ligne 486: Ligne 486:
 Dans un travail collaboratif, cette commande est fortement déconseillée. Mais si on est seul, cela peut servir. Dans un travail collaboratif, cette commande est fortement déconseillée. Mais si on est seul, cela peut servir.
  
-==== Garbage collection : Compresser les dépôts et libérer de l'espace ====+=== Garbage collection : Compresser les dépôts et libérer de l'espace ===
  
 La commande suivante compresse et nettoye le dépôt git : La commande suivante compresse et nettoye le dépôt git :
Ligne 494: Ligne 494:
 Cette opération peut prendre du temps0 Une fois terminé, on a gagné de l'espace disque. (gc = garbage collection). Cette opération peut prendre du temps0 Une fois terminé, on a gagné de l'espace disque. (gc = garbage collection).
  
-==== Extra 1 : .gitignore, Ignorer certains fichiers ====+=== Extra 1 : .gitignore, Ignorer certains fichiers ===
  
 Tous les fichiers du dossier de projet ne doivent pas être suivis par git. Par exemple : les fichiers objets, les fichiers d'échange, etc Tous les fichiers du dossier de projet ne doivent pas être suivis par git. Par exemple : les fichiers objets, les fichiers d'échange, etc
Ligne 500: Ligne 500:
 Créer un fichier nommé ‘.gitignore‘ dans le dossier de base du dépôt git et y inscrire le nom des fichiers comme expliqué ci-dessous, pour que git les ignore. Créer un fichier nommé ‘.gitignore‘ dans le dossier de base du dépôt git et y inscrire le nom des fichiers comme expliqué ci-dessous, pour que git les ignore.
  
-=== Les jokers simples sont reconnus ===+== Les jokers simples sont reconnus ==
  
 Les jokers ‘*‘ and ‘?‘ et les expressions régulières entre crochets `[ ]‘ sont reconnues. Les jokers ‘*‘ and ‘?‘ et les expressions régulières entre crochets `[ ]‘ sont reconnues.
Ligne 581: Ligne 581:
 </file> </file>
  
-=== A quoi sert .gitignore ? ===+== A quoi sert .gitignore ? ==
  
 Regardons un scénario typique de codage. Regardons un scénario typique de codage.
Ligne 595: Ligne 595:
 La solution : créer un fichier .gitignore dans le répertoire de base du projet avec une ligne contenant <<*. bak>>. La solution : créer un fichier .gitignore dans le répertoire de base du projet avec une ligne contenant <<*. bak>>.
  
-==== Extra 2 : Ajouter quelques couleurs et se présenter à git ====+=== Extra 2 : Ajouter quelques couleurs et se présenter à git ===
  
-=== Votre nom et votre adresse email dans les commits ===+== Votre nom et votre adresse email dans les commits ==
  
 Editer le fichier .git/config dans le dossier de base (le dossier du projet) et entrer les lignes suivantes. Editer le fichier .git/config dans le dossier de base (le dossier du projet) et entrer les lignes suivantes.
Ligne 617: Ligne 617:
 Une fois placés ces détails dans le dossier, au prochain commit, le nom et l'email sera enregistré comme ceux de l'auteur de ce commit. Une fois placés ces détails dans le dossier, au prochain commit, le nom et l'email sera enregistré comme ceux de l'auteur de ce commit.
  
-=== Coloriser la sortie de git ===+== Coloriser la sortie de git ==
  
 Un petit post de Gary explique comment faire : [[http://scie.nti.st/2007/5/2/colors-in-git]] Un petit post de Gary explique comment faire : [[http://scie.nti.st/2007/5/2/colors-in-git]]

Piste :