G.R.Y.S.

Come posso rimuovere un branch o un tag anche da server con Git ?
Usando semplicemente il comando

git branch -d -r origin/qualche_branch

lo si cancella fino al successivo pull

Per rimuoverlo definitivamente si deve usare il comando

git push origin :qualche_branch

in questo modo lo si elimina definitivamente

Piccolo corso su come creare un nuovo repository git su server remoto.

Prima di tutto si crea la directory che contiene il progetto in locale e si inizializza

mkdir test_project
cd test_project
git init
git remote add origin git@YOUR_SERVER_HOSTNAME:test_project.git

A questo punto si può lavorare nella directory come al solito.

Quando si decide di aver finito, si aggiungono i file con

git add .

e si committa tutto il lavoro

git commit -a

e poi si esegue il push con

git push origin master:refs/heads/master

e da qui il repository è pronto.

Questo approccio si può usare anche per importare dei sorgenti, basta scompattarli, entrare nella directory e dare il comando

git init

e poi seguire il resto dei passi.

…conservando la storia delle commit.

L’operazione è banale. Sono 3 semplici passi

1. Clonare il repository dal vecchio server

         git clone server:repository.git

2. Cancellare dal file .git/config la sezione [remote "origin"]
3. Importare nel nuovo server

      git remote add origin utente@server:repository

      git push origin master:refs/heads/master

Ed il gioco è fatto, buon lavoro

Ora che abbiamo il nostro server attivo, bisogna usarlo. I passi da fare sono i seguenti, facendo molta attenzione a non fare confusione con le chiavi pubbliche ssh, altrimenti non funziona nulla:

1. clonare il repository gitosis-admin git clone git@SERVER:gitosis-admin.git
2. modificare il file gitosis.conf per aggiungere un blocco simile a quello presente, ad es.

      [group devel]

      writable = vtf QtRegExp

      members = gianluca

3. committare le modifiche e fare il push del repository.

Se si vuole aggiungere una chiave pubblica di un nuovo utente con diritti di scrittura, basta copiare la chiave ssh (pubblica) nella directory keydir, aggiungere il file con git add e poi solita commit e push. Attenzione che il nome del file della chiave indica il nome dell’utente. Nel caso sopra quindi, avendo abilitato un utente “gianluca”, avrà in keydir un file gianluca.pub

Usando questa ottima guida, mi sono installato un server Git su uno slice comprato da slicehost.
I passi da seguire sono sostanzialmente quelli della guida, con la differenza che non serve installare gitosis dai sorgenti, ma va benissimo il pacchetto debian. I pacchetti minimi da installare sono gitosis e git-core. Dopodiché si possono seguire i passi della guida, con la differenza che la frase “Initialized empty Git repository in ./” per qualche motivo mi è saltata fuori solo due volte. Una volta fatto questo il server è attivo.
In pratica tutto il discorso, sotto Debian Lenny si riduce in questo comando:

apt-get install git-core gitosis

è anche possibile installare pacchetti aggiuntivi o complementari, ma non sono necessari (tuttavia git-doc è caldamente consigliato).

Al momento sto popolando i repository (contro di trasferirci QtNotes e Vtf per iniziare) e lo userò come repository dei miei sorgenti. Il link lo trovate nel BlogRoll a lato.

Per annullare una commit con git si può usare questa serie di comandi:

git-rev-parse --branch master

che restituisce la lista di commit per il branch master (o il branch indicato) in questa forma:

$ git-rev-parse --branch master

--branch

e17f9112b29b7e4294702188c7005db8d576f18e

A questo punto usando il comando

git revert e17f9112b29b7e4294702188c7005db8d576f18e

si torna indietro. Utile se si fanno danni durante la commit o si sbaglia la descrizione della commit.

Quando si vuole cambiare sistema di gestione dei sorgenti per passare da CVS o SVN a Git, ci si deve preparare ad un impatto con una realtà molto diversa da quella precedente, che all’inizio si può faticare a comprendere.Visto che ci sono passato, ho pensato di mettere insieme questo breve tutorial per il lavorodi tutti i giorni con Git.Il ciclo di lavoro con Git è simile a quello di CVS o SVN (se è per questo di un qualsiasi sistema di questo genere), cioè

• Update (o checkout) del repository
• Modifiche
• Commit

Le differenze cominciano a farsi notare da subito, visto che i comandi sono diversi anche se questo volendo non è poi così importante, quindi cominciamo a fare un po’ di esempi seguendo il ciclo di lavoro che abbiamo descritto sopra.

Scaricare un repository

La prima cosa da fare per cominciare a lavorare è scaricarsi il repository. Con git si usa questo comando:

git clone git+ssh://repo.or.cz/srv/git/qtodo.git

(facendo riferimento al mio progetto su quel sito)Questo comando scarica l’intero repository, con tutti i branch e tag. Git è infatti un version control system distribuito, quindi tutti hanno la copia di tutto il repository.

Lavorare con i sorgenti

Fatto questo si può cominciare a lavorare sui sorgenti. E qui cominciano a saltare fuori le differenze con sistemi tipo CVS e SVN. Nel caso di CVS ad esempio, se vogliamo lavorare su un certo branch dobbiamo scaricarlo esplicitamente dal server remoto. Nel caso di git invece abbiamo già tutto. Il comando

git branch [-r][-a][-d]

serve a visualizzare l’elenco dei branch presenti nella nostra copia del repository. Senza opzioni visualizza i branch locali, l’opzione -r serve a visualizzare i branch remoti, mentre l’opzione -a serve a visualizzare tutti i branch, locali e remoti. L’opzione -d serve a cancellare un branch locale oppure un branch remoto se utilizzata insieme all’opzione -r. Nella lista dei branch, l’asterisco (*) indica il branch corrente.A questo punto dovrebbe essere chiaro come procedere: con il comando

git checkout <-b> <branch>

si passa al branch che interessa. L’opzione -b è necessaria se è la prima volta che si esegue lo switch al branch desiderato, altrimenti non deve essere utilizzato Altre operazioni possibili sui branch sono la creazione di un nuovo branch con i comandi:

git branch nome_branch <branch di riferimento>

git checkout nome_branch

dove si crea il nuovo branch nome_branch, utilizzando eventualmente come base il <branch di riferimento> con il primo comando, e si passa ad esso con il secondo comando.Un comando più compatto è:

git checkout -b nome_branch <branch di riferimento>

che fa tutto in una volta, sia la creazione che lo switch al nuovo branch.

Commit e push delle modifiche

Dopo aver lavorato sui nostri sorgenti, siano essi nella master (l’equivalente di head) o in un branch, arriviamo al punto di consolidare le modifiche nel repository. Questo avviene in due passi distinti:

1. commit nel repository locale
2. commit (push) nel repository remoto

La prima operazione è simile nell’idea a quella che si farebbe con CVS o SVN, anche se ottiene risultati leggermente diversi. Usando il comando

git commit -a --no-verify -m"descrizione della commit"

si consolidano le modifiche nel repository locale, senza andare a sporcare quello remoto. Si possono effettuare tutte le commit che si vogliono sul repository locale senza dover necessariamente mandarle su quello remoto. E’ possibile effettuare la commit per un singolo file con il comando

git commit path/to/file --no-verify -m"descrizione della commit"

Una volta soddisfatti delle modifiche fatte e committate in locale, possiamo mandare le modifiche sul repository remoto con il comando <p class=”code”>

git push

si inviano tutte le commit effettuate sul branch corrente sul repository remoto in modo che siano visibili a tutti gli altri sviluppatori. Usando il comando

git push origin nome_branch

si invia al repository remoto il contenuto del branch nome_branch, anche partendo da un branch diverso. (Ad esempio, ho lavorato un po’ su master, poi su un branch e poi di nuovo su master, con questo comando posso spedire le modifiche committate sul branch senza dover fare lo switch)

Aggiornare un repository già scaricato

Ovviamente non è sempre necessario scaricare da zero un repository, esiste anche in git un comando per aggiornare un repository già scaricato in locale:

git pull <nome_branch>

aggiorna il repository locale partendo da quello remoto (l’equivalente del comando update di cvs o svn), aggiungendo nome_branch si aggiorna solo quello specifico branch.

Creare una release dei sorgenti

Una volta arrivati al momento di rilasciare, viene comodo il seguente comando:

git archive --format=tar --prefix=qtodo/ Ver_0.1.0 | gzip > qnotes_v0.1.0.tgz

che crea un file tar.gz che contiene i sorgenti del tree Ver_0.1.0 (in pratica il branch). Ovviamente git è parecchio più potente e consente di fare molte altre cose, ma questo articolo vuole solo essere un’infarinatura su come cominciare a lavorare usando git al posto di cvs o svn, non un tutorial completo, che magari arriverà in un futuro.

Ultimamente mi è venuto lo schizzo di mettermi a giocare con Git, il Version Control System usato tra l’altro per gestire i sorgenti Linux. Devo dire che dopo le prime incomprensioni (dovute principalmente a Windows a dire la verità ) sembra non essere male. Forse è anche troppo per le dimensioni del progettino con cui lo sto testando, ma così per provare può anche andare bene.Una cosa da ricordare: quando si fa una commit da Windows, i file devono essere in formato Unix, altrimenti git non gradisce molto l’iniziativa. (update: a questo di può ovviare usando lo switch –no-verify) Per la cronaca, il progettino è il software che farò vedere durante la serata introduttiva su python e qt che terrò al Lifos