Différences

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

--- environnement_prog_git [2009/12/14 16:27] – thierry
+++ environnement_prog_git [2012/04/05 08:45] (Version actuelle) – thierry
@@ Ligne 2: / Ligne 2: @@
 Liens:
+  *http://blog.rom1v.com/2012/04/prompt-bash-pour-git/
   *http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
   *http://linux.efrei.fr/doku.php/tutoriaux/git
   *http://progit.org/book/
 ===== Installation =====
@@ Ligne 166: / Ligne 168: @@
 On va cloner pour travailler sur le projet...
   $ git-clone ssh://<USER@MACHINE>/<PATH>/monprojet ./monprojet
@@ Ligne 174: / Ligne 178: @@
 Y a t'il eu des modifications à la source ?
   $ git-pull
   Already up-to-date.
@@ Ligne 182: / Ligne 187: @@
 Et puis "push":
-   $ git-push
+  $ git-push
   Counting objects: ....
   Compressing objects: ....
@@ Ligne 195: / Ligne 201: @@
 Alors j'ai fait:
   $ git-reset --hard
 Et voila...
@@ Ligne 201: / Ligne 209: @@
 La réponse est là: http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F
+En résumé: la mise a jour n'est pas faite a cause des conflits toujours possibles avec les modifications faites en local. Sinon, voir "post-update hook" and Co.
+| :!: en fait, il faut utiliser une repository "bare" (voir plus loin) , qui peut être modifier a loisir sans risque d'interference local |
 === origin ===
@@ Ligne 212: / Ligne 225: @@
     Tracked remote branch
       master
+=== bare ===
+voir "git-clone --bare" pour creer un "pur" repository .
+Lien: http://www.moroblog.info/Git-via-ssh.html
+Vite dit:
+  Soit un repository classique dans "./myproject"
+On clone avec "bare", ca créé un repertoire de données git.
+  $ git-clone --bare ./myproject ./myprojet.git
+On peut maintenant venir tirer et pousser des documents dans "./myprojet.git".
+Il n'y a pas de risque de conflit sur le repertoire de travail (avec les documents) puisqu'il n'existe pas.
+Cela permet de travail **vraiment** sur un repository a partir de plusieurs sites, y compris en local. (mais toujours en usant de "git-pull git-commit git-push" and so on)
 ==== exclude ====
@@ Ligne 244: / Ligne 276: @@
 On veut "fusionner" 2 partie d'un même projet, mais qui ce sont developpé independament.
+| :!: Par sécurité, j'ai fait ça dans un **''clone''** . Ce n'est que tout à la fin, une fois satisfait du résultat, que j'ai fait un **''push''** |
 Dans le répertoire du projet receveur:
-  $ git-remote add <un_nom_de_projet> <chemin_repo>
+  $ git-remote add -f <un_nom_de_projet> <chemin_repo>
-  $ git-fetch tlkref master
+( ''git-remote show'' peut maintenant nous montrer ce nom de projet)
-  warning: no common commits
-  remote: Counting objects: 61, done.
-  remote: Compressing objects: 100% (60/60), done.
-  remote: Total 61 (delta 30), reuremote: sed 0 (delta 0)
-  Unpacking objects: 100% (61/61), done.
-  From <chemin_repo>
-   * branch            master     -> FETCH_HEAD
   $ git-merge -s ours --no-commit <un_nom_de_projet>/master
-  <un_nom_de_projet>/master - not something we can merge  ???????
+  Automatic merge went well; stopped before committing as requested
   $ git-read-tree --prefix=<subdir/> -u <un_nom_de_projet>/master
+( les fichiers sont là, mais les logs ne sont pas à jour... )
   $ git-commit -a -m "fusion avec <un_nom_de_projet>"
   $ git-pull -s subtree <un_nom_de_projet> master
+( les logs contiennent aussi ceux du projet importé... )
+Et comme on a plus besoin du "remote"...
   $ git-remote rm <un_nom_de_projet>
 Et voila.
 "<subdir>" peut être "<un_nom_de_projet>".
+==== publier son git ====
+Lien: http://www.bluishcoder.co.nz/2007/09/how-to-publish-git-repository.html