Différences

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

--- linux:memo_git [24/06/2009 18:05] – daniel
+++ linux:memo_git [21/12/2012 11:23] (Version actuelle) – aj qq Commandes courantes daniel
@@ Ligne 2: / Ligne 2: @@
 Git est un gestionnaire de versions (comme svn, cvs ou d'autres) décentralisé.
-Bonne doc en français sur http://alexgirard.com/git-book/index.html
+Un bon résumé de git et de son fonctionnement sur http://www.siteduzero.com/tutoriel-3-254198-gerez-vos-codes-source-avec-git.html
-Mais, parfois, la centralisation s'avère pratique, et c'est aussi possible.
+Avant de se lancer, il vaut mieux lire au moins les chapitres 1 et 2 du livre pro git http://git-scm.com/book/fr (ou un autre), pour bien comprendre les concepts de base (git fonctionne sur des snapshots de l'état du dépôt, faut d'abord cerner ce qu'est un blob et un objet commit), pour éviter ensuite de se retrouver dans une situation où l'on croyait savoir mais on y comprend plus rien. Il faut faire la distinction entre
+  * workspace : le répertoire courant, changer de branche revient à faire un échange de snapshots de ce répertoire (ou d'une partie), pas à en changer (par opposition à svn où on passe de trunk à branche/ma_branche)
+  * index (ou stage) : la liste de ce qui se passera au prochain commit. Contrairement à svn on peut faire un commit de plusieurs fichiers, mais pas forcément dans leur état courant, on commit l'index, donc il faut faire un add (passer dans l'index) puis commit, même si souvent on fait un "commit -a" qui revient à ajouter à l'index tous les fichiers modifiés puis à faire le commit. Pour une utilisation basique, i.e. si on ne fait que des "commit -a" sans add préalable, on peut oublier cet état, mais attention si vous faite un add puis modifier le fichier, un git diff donnera alors la différence depuis le add, pas depuis le dernier commit (pour ça faut préciser "git diff HEAD"). Ne pas oublier : "un commit est un pointeur vers l'instantané du contenu qui a été indexé" (un snapshot de ce qu'on a mis en stage|index). **Rq** c'est ce que j'ai compris de la littérature mais chez mois un ''commit -m "commentaire" fichier'' envoie le fichier dans son état actuel et pas dans l'état du dernier add :-S
+  * local repository : la base git locale (qui contient tout l'historique du dépôt)
+  * remote repository : un dépôt distant, il peut y en avoir plein, et on peut avoir des branches qui pointent vers différents dépôt.
+  * stash : ça on peut s'en passer dans un 1er temps, même si c'est pratique. C'est un espace "tampon", pour y mettre ses modifs locales que l'on ne veut pas encore passer en commit (cf [[http://git-scm.com/book/fr/Utilitaires-Git-La-remise|la remise]] pour des exemples). Indispensable avant de changer de branche par ex.
+Résumé des commandes git
+  * graphique interactif efficace : http://ndpsoftware.com/git-cheatsheet.html
+  * http://jonas.nitro.dk/git/quick-reference.html
+  * http://cheat.errtheblog.com/s/git
+  * https://na1.salesforce.com/help/doc/en/salesforce_git_developer_cheatsheet.pdf
+  * chez [[http://doc.fedora-fr.org/wiki/Gestion_et_contr%C3%B4le_de_versions_avec_Git|fedora]]
+La référence (les pages man) : http://git-scm.com/docs
+Il y a aussi le  [[http://www.alexgirard.com/|git community book]] en fr, avec son [[http://www.alexgirard.com/git-book/book.pdf|pdf]]
+Des alias intéressant sur https://git.wiki.kernel.org/index.php/Aliases
+La page de doc du plugin netbeans http://netbeans.org/kb/docs/ide/git.html
+Tip & tricks
+  * http://mislav.uniqpath.com/2010/07/git-tips/
+===== Commandes courantes =====
+  * Modifier le dernier message de commit ''git commit --amend -m "New commit message"'' ([[http://stackoverflow.com/a/179147|src]])
+  * voir les serveurs distants (ajouter -v pour avoir les urls) ''git remote''
+  * editer la conf par defaut ''git config -e''
+===== Dépôt centralisateur =====
+Le décentralisé c'est très bien, mais parfois un dépôt qui centralise est bien pratique, et c'est aussi possible.
 Cf http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way,
@@ Ligne 11: / Ligne 43: @@
 Ensuite, quelques liens utiles
   * http://linux-attitude.fr/post/Git-%C3%A0-tous-les-%C3%A9tages
-  * http://jonas.nitro.dk/git/quick-reference.html
-  * http://cheat.errtheblog.com/s/git
   * http://alexgirard.com/git-book/3_workflows_distribu%25C3%25A9s.html
+  * http://xhfamily.com/x/notes/20080819_git-process.html
-===== Opérations courantes =====
+Pour créer un dépôt centralisé avec gitosis :
-http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#git-quick-start
+  * http://www.siteduzero.com/tutoriel-3-187504-heberger-des-depots-git-avec-gitosis.html
+  * http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
+Ce qui suit est assez ancien et à prendre avec des pincettes (m'étonne qu'il n'y ai pas --bare pour la création du dépôt centralisateur).
+==== Ajout d'un dépôt local sur le serveur ====
+Pour créer le dépôt, faut d'abord modifier gitosis.conf pour lister le nouveau repository sur la ligne
+writable du group qui va bien (pour déclarer qui aura le droit d'écrire sur ce dépôt). Et pour modifier ce gitosis.conf
 <code bash>
-# transformer le dossier courant en projet git
+# Si ce n'est déjà fait on récupère une copie localement (coté client donc)
+git clone git@<server>:gitosis-admin.git # on suppose que git est le user du server qui permet d'accéder aux dépôts)
+cd gitosis-admin
+joe gitosis.conf
+# ensuite on envoie ce fichier
+git commit -m 'ajout du dépot machintruc' gitosis.conf
+git push
+# et on peut balancer notre nouveau projet qui existe localement
+cd /path/2/mon_projet
+# si le dépot local git n'existe pas on le créé
 git init
-# ajouter tous ses fichiers au projet (ou bien préciser les fichiers à ajouter)
+# on ajoute tous les fichiers (mais on pourrait n'en préciser que certains seulement)
 git add .
-# ajouter un alias pour un projet sur un serveur distant
+git commit -a -m 'Premier commit'
-git remote add alias_de_ce_projet_sur_ce_serveur user@server:path/2/le_projet.git
+# on créé le dépot distant (on a déjà déclaré mon_projet dans gitosis.conf tout à l'heure), on l'appelle origin
-# y envoyer les fichiers
+git remote add origin git@<server>:<mon_projet>.git
-git push alias_de_ce_projet_sur_ce_serveur la_branche # "master" pour la branche principale
+# et on envoie sur le depot origin notre branche locale master
+git push origin master
+# pour les push suivant, on pourra faire un simple "git push"
+</code>
-# commit d`un fichier (localement)
+==== Rendre un dépôt public ====
-git commit -m 'message de commit' le_fichier
+Pour que des anonymes puissent cloner un dépôt, il faut dire à git-daemon qu'il peut l'exporter en lecture seule sans vérifier les clés ssh avec
-# commit de tous les fichiers (localement)
+<code bash>
-git commit -m 'message de commit' -a
+cd <le --base-path spécifié dans /etc/sv/git-daemon/run>
-# envoi de tous les derniers commit (depuis le dernier push) sur le serveur
+touch <mon_projet.git>/git-daemon-export-ok
+# et pour retirer ces droits de lecture anonyme il suffit d'effacer ce fichier vide.
+</code>
+==== Script de démarrage ====
+Avant le paquet git-daemon-run, il fallait créer un script de démarrage (cf historique de cette page), mais maintenant c'est dans debian :
+<code bash>
+aptitude install git-daemon-run
+ln -s /usr/bin/sv /etc/init.d/git-daemon
+# et on va modifier /etc/sv/git-daemon/run pour préciser le --base-path
+</code>
+===== Exemples =====
+Ci dessous qq démos, pour vous faire une idée.
+Les ligne qui commencent par "#>"  correspondent à la sortie de la commande précédente, pour permettre de copier/coller tout en console sans avoir de tri à faire
+==== Un local, plusieurs distants ====
+J'essaie ici d'avoir un dépôt local avec différentes branches qui suivent chacune son dépôt distant, mais le tracking marche pas comme ce que j'avais compris (testé en debian squeeze, avec git 1.7.2.5).
+Voici ce que j'ai fait (un seul serveur ici, mais si ça marche pour A...)
+<code bash>
+mkdir serveurA
+cd serveurA/
+h=$(basename $(pwd)); touch $h a c; echo $h > c;
+git init --bare
+# un clones (pour vérifier que le push sur les serveurs est bien ce qui est attendu)
+cd ..
+git clone serveurA cloneA
+# et aussi pour le peuplement initial
+cd cloneA
+h=$(basename $(pwd)); touch $h c1 c2; echo $h > c2;
+git add .
+git commit -a -m "1er commit $h"
+git push origin master
+# et un dépôt local
+cd ..
+mkdir loc
+cd loc
+git init
+# avec qq fichiers
+h=$(basename $(pwd)); touch $h c2; echo $h > c2;
+git add .
+git commit -a -m "1er commit $h"
+# ça nous a créé une branche master, mais on veut la nommer autrement pour pas confondre avec ceux des remote
+# et éviter d′éventuel push/pull non désiré entre ce ce master local et les remote
+git branch -m master commun
+# un alias pour le serveur
+git remote add remoteA ../serveurA master
+# une branche que l′on va synchroniser avec le serveur A
+git fetch remoteA                               # => 1er fetch donc créé la "branche" remoteA/master
+git checkout --track -b brancheA remoteA/master # => créé la branche brancheA en lien avec remoteA/master
+# on modifie un fichier
+echo  "mod 1" > cloneA
+git commit -m "mod 1" cloneA
+# que l′on veut envoyer
+git push
+#>Everything up-to-date
+# Ah bon ? Le tracking marche pas ?
+git push remoteA brancheA:master
+# ça push mieux
+# 2e modif pour voir si ça track mieux maintenant qu′on lui a montré
+echo  "mod 2" >> cloneA
+git commit -m "mod 2" cloneA
+git push
+# tj rien :-S, et avec -u ?
+git push -u remoteA brancheA:master
+#> [...]
+#> To ../serveurA
+#>    3b00bff..cb44c59  brancheA -> master
+#> Branch brancheA set up to track remote branch master from remoteA.
+# ça parait pourtant clair, mais
+echo  "mod 3" >> cloneA
+git commit -a -m "mod 3"
 git push
+#> Everything up-to-date
+# pas mieux...
 </code>