facciamo che intanto lo posto qui. essendo la prima volta che armeggio con git non è detto che non abbia fatto passi errati o me ne sia dimenticati altri. attendo eventuali commenti per modificare/migliorare la mini guida.
[nota iniziale: questa mini-guida sull'uso di gift è ancora sperimentale, è basata su fatti realmente accaduti grazie all'ispirazione data dalle 2 guide di moodle su Git consigliate da andrea e dal manuale italiano di Git stesso. il mio scopo era attivare una procedura che mi permettesse di tenere aggiornato moodle senza perdere i miei hack al codice, potendoli ri-applicare automaticamente sui nuovi file ufficiali. spero questa guida possa ispirarvi, aiutarvi e, soprattutto, essere migliorata con il vostro contributo.]
[START]
ho installato git (ottima guida in italiano con un passo-passo: http://git-scm.com/book/it/Per-iniziare )
via terminale:
ho configurato git (lavoro su ambiente osx 10.6 server, per editor e diff tool differenti verdere la guida citata)
$ git config --global user.name "Mio Nome"
$ git config --global user.email mia@email
$ git config --global core.editor nano
$ git config --global merge.tool opendiff
mi sono spostato nella cartella che dovrà ospitare il mio moodle pubblico
$ cd <cartella pubblica del server http>
ho clonato il brach di moodle
$ git clone git://git.moodle.org/moodle.git
[nota: così i file vengono copiati in una cartella chiamata "moodle". se si vuole chiamarla diversamente basta aggiungere il nome scelto, es.:
$ git clone git://git.moodle.org/moodle.git moodleonline
oppure fare un "mv moodle moodleonline" al termine dell'operazione di clone]
ho richiesto i rami disponibili
$ cd moodle
$ git branch -a
ho preso il brach stabile più recente
$ git branch --track MOODLE_24_STABLE origin/MOODLE_24_STABLE
$ git checkout MOODLE_24_STABLE
via browser:
ho proveduto all'installazione on line
http://<miosito>/install
ecc.
[nota: potrebbe essere necessario prima effettuare un chown per ridare poteri di scrittura all'utente dell'httpd (www, www-data, ecc. a seconda del sistema). oppure il file config.php andrà creato poi a mano]
torno al terminale per testare il tutto:
nella directory dell'installazione (in questo esempio "moodle") ho creato un file
$ nano testgit.txt
ho controllato lo stato del repository
$ git status
# On branch MOODLE_24_STABLE
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# testgit.txt
nothing added to commit but untracked files present (use "git add" to track)
ho modificato un file ("brokenfile.php"), modificando una semplice riga di commento
$ nano brokenfile.php
ho ricontrollato lo stato
$ git status
# On branch MOODLE_24_STABLE
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: brokenfile.php
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# testgit.txt
no changes added to commit (use "git add" and/or "git commit -a")
mi dice che vi sono modifiche non ancora registrate nel repository e un file nuovo non tracciato
ho quindi aggiunto le mie modifiche al track
$ git add brokenfile.php
$ git add testgit.txt
ricontrollo lo status
$ git status
# On branch MOODLE_24_STABLE
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: brokenfile.php
# new file: testgit.txt
#
mi dice che vi sono cambi da registrare
nota: per controllare le modifiche PRIMA di aggiungerle al track
$ git diff
per controllare DOPO averle aggiunte
$ git diff --cached
in entrabi i casi l'esito è qualcosa di simile:
diff --git a/brokenfile.php b/brokenfile.php
index 3153ade..691ff72 100644
--- a/brokenfile.php
+++ b/brokenfile.php
@@ -1,6 +1,6 @@
<?php
// This file is part of Moodle - http://moodle.org/
-//
+//remu test
// Moodle is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
nota: se si fanno modifiche ad un file che è già stato aggiunto nella cache ma non ancora registrato (committed) occorre aggiungerlo di nuovo (git add) o comparirà 2 volte nello status (nel gruppo "Changes not staged for commit" e nel gruppo "Changes to be committed")
ora confermo i miei patch lanciando il commit
$ git commit -v
(nota: con l'opzione -v il comando commit aggiunge - nel report che genera - le modifiche apportate. io lo trovo molto utile. per altre opzioni vedere la guida che cito in alto)
si apre automaticamente l'editor impostato in git (io uso "nano") con il messaggio del commit. la prima riga è vuota: lì va scritto il proprio messaggio pro-memoria (tipo "aggiunto commento di test 2013-04-15"). le righe successive, commentate, sono l'ultimo status, possono essere cancellate. infine, se si è usata l'opzione -v, si ha la traccia dei cambiamenti.
salvo il file
chiudo l'editor
compare la conferma:
[MOODLE_24_STABLE 3f34e25] aggiunto commento di test 2013-04-15
2 files changed, 2 insertions(+), 1 deletions(-)
create mode 100644 testgit.txt
se ricontrollo lo status:
$ git status
# On branch MOODLE_24_STABLE
# Your branch is ahead of 'origin/MOODLE_24_STABLE' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
mi dice appunto che la mia versione è "oltre" quella ufficilae (master). e, volendo, potrei pubblicare i miei patch per condividerli (per far questo occorre però procedere diversamente, seguendo la guida "gift for developers" citata da Andrea)
nota: con il comando
$ git log
posso verificare tutte le modifiche che sono state apportate al ramo (vi sono varie opzioni, vedere la guida che cito in alto), con info sull'autore. comprese le mie (esistenti a livello locale).
[END]
a questo punto, sono sicuro che le mie modifiche saranno mantenute e quelle ufficiali del branch pure. starà a me applicarle.
mi verrebbe da concludere così:
l'unica avvertenza è: prima di applicare (commit) le modifiche ufficiali quando ci saranno, occorre controllare che non contrastino con le nostre.
questo pezzo ancora mi manca, come esperienza. attendo di arrivarci… o commenti da chi usa questa procedura.
altro pezzo che ancora mi manca è: quando effettuo l'aggiornamento (git pull ecc come spiegato nella guida per amministratori) via git vedo tutto quello che accade e decido se accettare o meno le modifiche. ma che succede se l'aggiornamento viene fatto on line, via pagina amministrativa del front-end? devo disattivare tale opzione oppure semplicemente dovrò poi riapplicare le mie patch registrate sul repository git? appena ne saprò di più, aggiungerò qualche nota. o, se qualcuno già sa, è il benvenuto… 