GIT

• Git Book LE site Git, très complet
• Si vous n'avez que quelques minutes, liste ce Petit guide il va vraiment à l'essentiel.
• Git Cheat sheet (tirée du site précédent)

Par les dépots

sudo apt-get install git

un peu compliqué non ?

git config --global user.name "Your_Name"
git config --global user.email "youremail@domain.com"

Ces commandes vont avoir pour effet de renseigner le fichier ~/.gitconfig en lui ajoutant :

[user]
        name = Your_Name
        email = youremail@domain.com

Déclarer un dossier comme projet git.
Se placer dans le répertoire en question et :

git init

ou pour directement récupérer le contenu d'un projet existant :

git clone url_du_repository

url_du_repository peut prendre plusieurs formes, selon le protocole utilisé :

• ssh :

  utilisateur@serveur:/chemin/projet.git

• http :

  http://exemple.com/projetgit.git

• local et git : voir cette documentation

NB : Il faut être placé dans le dossier du repository …

git add mon_fichier.txt

On peut procéder ainsi pour plusieurs fichiers, mais il est aussi possible d'indiquer tout un répertoire (et son arborescence) :

git add .

git rm fichier.txt

git rm --cached fichier.txt

git mv ancien_nom nouveau_nom

git commit -am "un message"

git status

Connaitre l'historique des commits

git log

git log -p <filename>

Revenir en arrière

git checkout [chemin et nom du fichier]

git push origin master

push : envoyer
origin : nom par défaut du serveur remote
master : branche courante

git pull origin master

Supposons qu'on ait une version stable d'un programme, passée en prod.
On décide de travailler sur une nouvelle fonctionnalité (pour ca on édite nos fichiers locaux) quand un bug trouvé en production nécessite qu'on le corrige immédiatement.
Problème : ce qu'on est en train de faire n'est pas terminé et ne peut pas être passé en production, donc si on résout le bug et qu'on commit, on enverra aussi le code non finalisé (en supposant qu'il est dans le même fichier que le bug …). Donc, il faut pouvoir mettre de côté ce qu'on est en train de faire.
Les branches permettent cela, mais aussi, en restant dans la même branche, le stash :

# je travaille sur mon programme
touch fichier.txt
echo "premiere edition" >>fichier.txt
# je le passe sur le serveur, pour le passer en production.
git add . 
git commit -m "premiere edition" 
git push origin master
# maintenant je decide de travailler sur une nouvelle fonctionalite, quand je suis interrompu
echo "deuxième édition, pas terminée... ">> fichier.txt  
#on met de côté l'édition en cours car on doit traiter une urgence 
git stash 
# on est retourné sur le précédent commit
#on édite puis on commit... 
echo "correction du bug" >>fichier.txt
git commit -am "correction du bug"
git push origin master
# on revient sur l'édition en cours 
git stash pop

astuce trouvée ici

Si au fur et à mesure des commits, ou après un git clone, le .gitignore peut ne plus fonctionner, Git indexe alors des fichiers qui ne le devraient pas. Il faut donc tout réinitialiser.

• archivage de tout le code modifié non versionné ;
• suppression de l'index

git rm -r --cached .

• réimportation de tout l'index (le .gitignore est maintenant pris en compte) :

git add .

• commit des changements :

git commit -m ".gitignore est maintenant fonctionnel"