Installation
apt-get install git-core
Configuration
- Fichier /etc/gitconfig : Contient les valeurs pour tous les utilisateurs et tous les dépôts du système. Si vous passez l’option –system à git config, il lit et écrit ce fichier spécifiquement.
- Fichier ~/.gitconfig : Spécifique à votre utilisateur. Vous pouvez forcer Git à lire et écrire ce fichier en passant l’option –global.
- Fichier config dans le répertoire Git (c’est à dire .git/config) du dépôt en cours d’utilisation : spécifique au seul dépôt en cours. Chaque niveau surcharge le niveau précédent, donc les valeurs dans .git/config surchargent celles de /etc/gitconfig.
Sur les systèmes Windows, Git recherche le fichier .gitconfig dans le répertoire $HOME (C:\Documents and Settings\$USER la plupart du temps). Il recherche tout de même /etc/gitconfig, bien qu’il soit relatif à la racine MSys, qui se trouve o๠vous aurez décidé d’installer Git sur votre système Windows.
Collé à partir de <http://git-scm.com/book/fr/D%C3%A9marrage-rapide-Param%C3%A9trage-%C3%A0-la-premi%C3%A8re-utilisation-de-Git>
configurer un utilisateur
afin d’identifier qui fait quoi
git config –global user.name « Guillaume Jacquemoud »
git config –global user.email « g.jacquemoud@ultimeo.com »
git config –global core.editor nano
git config –global –add color.ui true
git config alias.st status
git config alias.ct commit
git config alias.ck checkout
git config alias.br branch
lister la config
git config –list
alias]
st = status
ct = commit
ck = checkout
br = branch
Ignorer les fichiers inutiles
Le fait d’indiquer à Git d’ignorer des fichiers inutiles permet de ne conserver la trace que des modifications apportés au code lui-même.
Les changements dans les fichiers temporaires par exemple sont trop fréquents et inintéressants. Nous allons donc tout bonnement ignorer ces fichiers.
Voici une liste non exhaustive de fichiers à ignorer :
- des fichiers temporaires : logs, cache…
- des fichiers uploadés par les utilisateurs
- des fichiers dépendant de l’environnement : configuration de la base de données, index.php, .htaccess…
Git stocke la liste des fichiers à ignorer dans un fichier .gitignore situé à la racine de l’application. Nous créons ce fichier et y ajoutons le contenu suivant :
# .gitignore
tmp/**/*
tmp/**/**/*
.htaccess
config/core.php
config/config.php
config/database.php
webroot/.htaccess
webroot/index.php
webroot/test.php
!.gitignore
La syntaxe avec les étoiles permet d’ignorer tous les sous-répertoires de tmp.
Enfin, dernière chose, nous devons également indiquer à Git de ne pas ignorer les fichiers .gitignore présents dans les répertoires vides. Nous ajoutons pour cela en fin de fichier .gitignore la ligne
!.gitignore
Configurer un dépôt privé
- Il faut avoir déjà un projet de créé dans un dossier ex : /var/www/projet1/
- Avoir fait un git init et des commits
- Allez dans votre dossier o๠stocker les repositories ex : /var/repos/
- Faire
git clone –bare /var/www/projet1/.git /var/repos/mondepot.git
Collé à partir de <http://www.alexgirard.com/git-book/4_configurer_un_d%25C3%25A9p%25C3%25B4t_priv%25C3%25A9.html>
Configurer un serveur remote
git remote add ‘prod’ /var/www/repository/ultimeo/tgit/master.git
Les commandes
Initialisation
Sur un projet
Allez dans un dossier de développement (/var/www/projet1/) et en shell taper :
git init
Pour un repository
Initialise un repo git vide
Allez dans un dossier de accessible (/home/phpuser/git/) et en shell taper :
mkdir projet1.git
cd projet1.git
git –bare init
Ajouter un remote (repository) à son instance git
git remote add prod /var/www/repository/ultimeo/tgit/master.git
git remote add origin ssh://phpuser@web1.toto.fr:1987/home/phpuser/git/projet1.git
Commit
git add .
git commit -am « message du commit »
Réparer une erreur non-committée
Si vous vous êtes embrouillé dans votre répertoire de travail, mais que vous n’avez pas encore committé vos erreurs, vous pouvez retrouver l’état dans lequel était votre répertoire après le dernier commit en utilisant :
$ git reset –hard HEAD
Cela effacera toutes les modifications que vous avez ajouté à l’index git ainsi que les changements qui sont présents dans votre répertoire de travail mais qui n’ont pas été ajoutés à l’index. En d’autres termes, après cette commande, le résultat de git diff et git diff –cached sera vide.
Si vous ne voulez restaurer qu’un seul fichier, par exemple hello.rb, utiliser plutôt git checkout :
$ git checkout — hello.rb
$ git checkout HEAD hello.rb
La première commande restaure hello.rb à la version de l’index afin que git diff hello.rb ne retourne aucune différence. La seconde commande restaurera hello.rb à la version de la révision HEAD afin que git diff hello.rb et git diff –cached hello.rb ne retourne aucune différence.
Réparer une erreur committée
Si vous avez déjà committé ce que vous n’auriez pas dà», il y a deux faà§ons fondamentalement différentes de régler le problème :
- Vous pouvez créer un nouveau commit qui annule les changements du dernier commit. C’est la manière correcte de s’y prendre si votre erreur est déjà publique.
- Vous pouvez revenir en arrière et modifier l’ancien commit. Vous ne devriez jamais faire à§a si vous avez déjà rendu l’historique public. Git n’est pas conà§u pour que l’historique d’un projet change et ne peut pas effectuer correctement des fusions répétés sur depuis une branche qui a vu son historique modifié.
Réparer une erreur sur un nouveau commit
Il est facile de créer un nouveau commit qui annule les changements d’un commit précédent. Utilisez la commande git revert avec la référence du mauvais commit, par exemple, pour revenir au commit le plus récent :
$ git revert HEAD
Cela créera un nouveau commit qui annulera les changements dans HEAD. Vous pourrez éditer le message de ce nouveau commit.
Vous pouvez aussi revenir sur des changements plus anciens, par exemple, sur l’avant-dernier changement :
$ git revert HEAD^
Dans ce cas, git essayera d’annuler l’ancien changement en gardant intactes les modifications faites depuis. Si plus d’un changement se superpose sur les changements à annuler, vous aurez à régler les conflits manuellement, de la même faà§on que quand vous réglez une fusion.
Réparer une erreur en modifiant le commit
Si vous venez de committer quelque chose mais que vous vous rendez compte que vous devez réparer ce commit, les versions récentes de git commit vous donnent accès à l’option –amend qui demande à git de remplacer le commit de HEAD par un autre, basé sur le contenu actuel de l’index. Cela vous donne l’opportunité d’ajouter de fichiers que vous avez oubliés ou de corriger des erreurs de typo dans le message du commit, avant de publier les changements pour les autre développeurs.
Si vous trouvez une erreur dans un ancien commit, mais que vous ne l’avez toujours pas publié, utilisez le mode interactif de git rebase, avec git rebase -i en marquant les changements qui doivent être corrigés avec edit. Cela vous permettra de modifier le commit pendant le processus de recombinaison.
Collé à partir de <http://www.alexgirard.com/git-book/4_r%25C3%25A9paration_avec_git_%25E2%2580%2594_reset%252C_checkout_et_revert.html>
Branches
Lister les branches existantes
- en local
git branch
- local + celles des remotes
git branch -a
Créer une branche
git banch mabranche
Changer de branche
git checkout mabranche
pousser une branche
git push prod mabranche
tirer une branche (sur la branche en cours)
git pull prod mabranche
Merger une branche depuis une autre
ex : on a la branche master et une branche de dev mabranche. On corrige un bug sur le master pour remonter cette correction sur mabranche on fait:
se mettre sur la branche de destination
git checkout mabranche
git merge master
Dans la plus part des cas on sera dans le cas inverse : le dev sur mabranche est fini, on le fusionne avec le master:
git checkout master
git merge mabranche
Recombinaison (rebase)
Cette commande va retirer chacun de vos commit sur ‘mywork’, en les sauvegardant temporairement comme des patches (dans le dossier « .git/rebase »), puis mettre à jour la branche ‘mywork’ avec la dernière version de la branche ‘origin’, et enfin appliquer chaque patch sauvegardé à cette nouvelle version de ‘mywork’.
Une fois que la référence (‘mywork’) est mise à jour jusqu’au dernier objet commit créé, vos anciens commits seront abandonnés. Ils seront sà»rement effacer si vous lancer la commande de ramasse-miettes. (voir git gc)
Dans le processus d’une recombinaison, des conflits peuvent se produire. Dans ce cas, le processus s’arrêtera et vous permettra de réparer ces conflits; après les avoir fixés, utilisez « git-add » pour mettre à jour l’index avec ce nouveau contenu, puis, au lieu de lancer git-commit, lancez juste:
$ git rebase –continue
et git continuera d’appliquer le reste des patches.
à€ n’importe quel moment, vous pouvez utiliser l’option –abort pour annuler le processus et retourner au même état de ‘mywork’ qu’au démarrage de la recombinaison:
$ git rebase –abort
Collé à partir de <http://alx.github.com/gitbook/4_recombinaison_(rebase).html>
Supprimer une branche
- se mettre sur une autre branche !
git branch -d mabranche
Afficher les logs formatés :
git log –pretty=format: »%h par %an, %ar, => %s »
git log –pretty=format: »%h par %an, %ar, => %s » –graph
http://git-scm.com/book/fr/Les-bases-de-Git-Visualiser-l%27historique-des-validations
=> pour sortir de git log : q
Git Status
La commande git status vous indique les fichiers que vous avez modifiés récemment
Cloner un repo
git clone monrepo
clone une branche spécifique
git clone -b nomdebranche monrepo
Virer les infos git :
find $TARGET -name .git | xargs rm -rf –
find $TARGET -name .gitignore | xargs rm -rf –
find $TARGET -name .gitmodules | xargs rm -rf –
find $TARGET -name .svn | xargs rm -rf –
Collé à partir de <http://www.alexgirard.com/git-book/3_analyser_l%25E2%2580%2599historique_%25E2%2580%2594_git_log.html>