Ceci est une ancienne révision du document !
Table des matières
Git
Quelques rappels de base sur l'utilisation du gestionnaire de version Git.
Note : les principaux éléments indiqués ici sont déstinés à une utilisation sous Windows avec le shell msysGit. Cela signifie que les lignes de commande seront “linux-style”, mais que les chemin et logiciels utilisés seront “windows-style”.
Général
Configurer Git
Configurer son environnement :
# modifier la configuration pour tous les utilisateurs git config --system <clé> <valeur> # modifier la configuration pour l'utilisateur connecté git config --global <clé> <valeur> # modifier la configuration pour le projet courant git config <clé> <valeur>
Lire la configuration :
# consulter la configuration git config <clé> # consulter tous les éléments de configuration git config --list
Configurations utiles (celles à faire avant d'utiliser git) :
git config --global user.name "Name" git config --global user.email name@domain.com git config --system https.proxy http://<proxy-url>:<proxy-port> //or git config --system https.proxy http://<login>:<password>@<proxy-url>:<proxy-port>
Aide
git help <command>
Projet : gestion de base
Note : toutes les commandes relatives à un projet doivent être effectuée après s'être placé dans le dossier du projet
cd /to/the/source/directory #les lecteurs "windows" sont indiqués par /d/ au lieu de D:\ dans le bash de git cd /d/project-directory/source-directory
Configurer un projet
Initialiser le projet (créé un sous-dossier “.git”) :
git init
Nouveau projet
“Ajouter” chaque fichier source qu'on veut versionner à git :
git add <filepattern>
Exemples :
git add fichier.c git add *.c git add *
Note : sauf erreur de ma part, '*' ne prend pas en compte les sous-répertoires et leurs contenus.
Projet existant
Pour partir d'un projet déjà présent dans un repository git (local ou distant) :
git clone <local-path>/<project>.git git clone git://<git-url>/<project>.git git clone http(s)://<url>/<project>.git
Note : un dossier <project> sera créé. Il faut donc se placer dans le dossier parent de celui où on voudra placer les sources.
Informations
Etat des fichiers
Pour connaître l'état d'un fichier (untracked, modified, staged, etc…) :
git status
Pour avoir des informations plus détaillées :
git diff #compare your version with your staged version git diff --cached #compare your staged version and the last commited version git diff --staged #same as --cached
Historique : accès aux commits
Lister les commits (et leurs commentaires)
git log git log -p #shows the diff introduced in each commit git log -<number> #shows only the last <number> commits git log --since=2.weeks #shows only commits for the past 2 weeks git log --stat #gives a few stats (nb of files changed, lines added or removed) git log --pretty=format:"%h %s" --graph #shows a view of branches and merges
Préparer un commit
Marquer un fichier comme prêt à être commité suite à modification se fait aussi via la commande git add. Il sera alors considéré comme “staged”.
Si on “git add” plusieurs fois d'affilé un même fichier (suite à des modifs), seule la dernière version est conservée, tandis que si on effectue un commit à chaque fois, alors toutes les versions seront dans le repository.
Commit
Une fois les modifications “staged”, on peut enfin commiter, c'est-à-dire transmettre cette version “staged” au repository (qu'il soit local ou distant).
git commit git commit -v #verbose: shows the diff while you write the comment git commit -m "Message..." #to write the commit comment directly in command-line git commit -a #skips the staged area and commit directly your version
Un fichier texte s'ouvre dans l'éditeur de texte défini par défaut dans la config de git, pour permettre la saisie du commentaire du commit.
git config --global core.editor "'C:\Program Files\Sublime Text 2\sublime_text.exe' -w"
…pour définir Sublime Text 2 comme éditeur par défaut.
Si vous commettez un erreur lors de votre dernière commit, il est toujours possible de la rattraper. Après avoir apporté la modification en local puis à la version “staged” :
git commit --amend
Ignorer des fichiers
Pour exclure certains fichiers ou types de fichiers de nos commit, il faut créer un fichier .gitignore et y lister les éléments à exclure.
file.ext /README #ignore the root README, but not ones in subdirectories *.doc !test.doc #exception for rules listed above : test.doc will NOT be ignored thisDirectory/ #...and everything in it #or any glob syntax, including: [aoe], [0-9], *, ?
Retirer des fichiers
Pour supprimer un fichier partout :
git rm Supprime-Moi.txt git commit -m "Suppression de fichier inutile"
Git rm retire le fichier du dossier de travail et de la version “staged”, donc il faut ensuite effectuer un commit pour appliquer la modif au repository. L'historique du fichier reste dans le repository.
Par contre si vous ajoutez un fichier au .gitignore un peu tard et qu'il est déjà “staged” ou commité, il faut ajouter –cached à la commande. Le comportement sera identique sauf que le fichier ne sera pas supprimé du dossier de travail.
git rm --cached Supprime-Moi.txt
Déplacer/Renommer un fichier
Comme la commande mv de linux. Cela évite de déplacer/renommer le fichier à la main, puis de supprimer l'ancien des fichiers “staged” et d'y ajouter le nouveau.
git mv source.txt directory/destination.txt
"Unstaged"
Si vous avez ajouté à la version “staged” un fichier et voulez l'en retirer :
git reset HEAD monFichier.php
Annuler les modifications d'un fichier
Si vous voulez écraser un fichier pour revenir à la dernière version “staged” ou commitée
git checkout -- monFichier.php
Attention cependant : toute modification apportée localement sera perdue.
Remote repositories
Les remotes sont des répertoires hébergeant les versions d'un projet généralement à distance (internet, réseau). Cela permet d'y conserver toutes les sauvegardes, d'y travailler à plusieurs, etc…
Informations
git remote #lists all remotes configured for the current project git remote -v #same list with urls
Chaque remote comporte un nom librement choisi par l'utilisateur
Plus de détails sur un remote :
git remote show custom-name
Ajout d'un remote
git remote add custom-name git://git@domain.com/path/project.git git remote add custom-name https://domain.com/path/project.git git remote add custom-name /d/path/to/local/remote/project.git
Récupérer les données d'un remote
git fetch custom-name git pull custom-name
Si fetch récupère les information, il ne les fusionne pas avec les versions locales, contrairement à pull.
Quand on a récupéré un projet existant via clone, le nom attribué au remote est par défaut origin. Pour le mettre à jour par la suite :
git fetch origin
Transmettre des données à un remote
Lorsqu'on commit, la version est stockée dans le repository local (sous-répertoire .git de notre projet). Pour transmettre ces données au remote repository :
git push <remote name> <branch name>
La branche par défaut est master, tout comme le nom de remote par défaut est origin. Souvent vous n'aurez qu'à faire :
git push origin master
Note : certains serveurs ne vous seront accessible qu'en lecture : vous pourrez faire des pull, mais pas de push
Renommer/Retirer un remote
git remote rename old-name new-name #rename remote git remote rm custom-name #remove remote
Tag : étiquetter ses version
Les tags sont des étiquettes ajoutées au repository qui servent juste à désigner une étape importante dans le développement, comme par exemple un numéro de version.
git tag #lists existing tags git tag -a <tag name> -m <message> #adds a tag git tag -a v1.2 -m "My favorite version" git show v1.2 #shows information about this tag
Comme on le voit, ces tags (“annotated tags”) sont en quelque sorte des commits qui n'apporteraient aucun changement au code.
Par opposition, il existe aussi des tags “léger” (“lightweight”), en quelque sorte temporaires. Pour cela, on n'ajoute pas d'option à la commande, sauf le nom du tag :
git tag v1.3b1
Ces tags seront listé avec les autres, mais si on fait un show dessus, on retirera moins d'informations.
Si on souhaite ajouter les tags après coup, alors qu'on a fait des commits depuis, on peut préciser après quel commit insérer le tag en ajouter le début de son checksum en fin de commande :
git tag -a v1.1 -m "J'avais oublié celui-là" 305bdd6
Partager les tags
Par défaut, ces tags ne sont pas transmis par push, à moins de le préciser :
git push origin --tags
Les tags “légers” seront aussi transmis.