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  :

  1. 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.
  2. 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://www.alexgirard.com/git-book/3_analyser_l%25E2%2580%2599historique_%25E2%2580%2594_git_log.html

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>