Introduzione a GIT

Un nuovo progetto

Iniziamo un nuovo progetto che vogliamo salvare sotto git: non serve preoccuparsi di avere un server, e neanche un nome pubblicabile per il progetto, basta creare una directory (che potremo rinominare in futuro), dire a git di crearci un repository e poi si può inizare subito a lavorare.

$ mkdir greeter
$ cd greeter/
$ git init
Initialized empty Git repository in /home/[...]/greeter/.git/

Qualche file

Creiamo i nostri file, in questo caso un programma in python che saluterà le persone.

$ mkdir greeter
$ touch greeter/__init__.py
$ cat > greeter/greeter.py
class Greeter:
    """ """
$ cat > greeter.py
#!/usr/bin/env python

def main():
    pass

if __name__ == '__main__': main()
$ chmod 755 greeter.py

GIT

Con git status possiamo vedere che git si è accorto dell'esistenza di alcuni file, ma sono untracked, ovvero non considerati dal controllo delle revisioni.

$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       greeter.py
#       greeter/
nothing added to commit but untracked files present (use "git add" to track)

In staging

Aggiungiamo quel che abbiamo fatto alla staging area, ovvero diciamo a git di prendere in considerazione quella versione del file perché venga successivamente salvata.

$ git add greeter.py greeter/
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   greeter.py
#       new file:   greeter/__init__.py
#       new file:   greeter/greeter.py
#

Altre mod

Facendo altre modifiche e riguardando git status ci possiamo accorgere di come git non salvi automaticamente tutti i cambiamenti presenti nei file di cui tiene traccia, ma solo quelli che gli vengono indicati esplicitamente da salvare.

$ cat > greeter/__init__.py
from greeter import Greeter
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   greeter.py
#       new file:   greeter/__init__.py
#       new file:   greeter/greeter.py
#
# 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:   greeter/__init__.py
#

Ultimi preparativi

A questo punto possiamo aggiungere anche le ultime modifiche:

$ git add greeter/__init__.py
$ git commit

Se è la prima volta che usiamo git su questo computer salviamo qualche informazione su di noi, nel mio caso:

$ git config --global user.name "Elena ``of Valhalla'' Grandi"
$ git config --global user.email valhalla@trueelena.org

Commit

E finalmente possiamo creare il nostro primo commit, un insieme di file in una loro determinata versione al quale vengono associati alcuni metadati (autore, data, ...) e soprattutto un identificativo che è un hash crittografico dei contenuti.

Il comando git commit apre un editor con il quale scrivere un commento da associare al commit. Di solito si scrive una descrizione breve da una riga (una 60ina di caratteri), e poi eventualmente altre informazioni più approfondite.

Skeleton for the new project.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   greeter.py
#       new file:   greeter/__init__.py
#       new file:   greeter/greeter.py
#

Commit (2)

".git/COMMIT_EDITMSG" 14L, 377C written
[master (root-commit) b54e94f] Skeleton for the new project.
 3 files changed, 9 insertions(+)
 create mode 100755 greeter.py
 create mode 100644 greeter/__init__.py
 create mode 100644 greeter/greeter.py

log

Con il comando git log possiamo vedere l'identificativo completo del commit appena fatto, e qualche metadato.

$ git log
commit b54e94fde972281ca31a56ef0d36204addd4906b
Author: Elena ``of Valhalla'' Grandi <valhalla@trueelena.org>
Date:   Thu Nov 15 19:05:42 2012 +0100

    Skeleton for the new project.

Show

E con git show possiamo vedere i dettagli del commit, con tutte le modifiche che sono state introdotte (sotto forma di diff dalla versione precedente).

Possiamo vedere come non serva scrivere tutto l'identificativo del commit, ma bastino i primi caratteri sufficienti ad identificarlo univocamente nel repository.

$ git show b54e
commit b54e94fde972281ca31a56ef0d36204addd4906b
Author: Elena ``of Valhalla'' Grandi <valhalla@trueelena.org>
Date:   Thu Nov 15 19:05:42 2012 +0100

    Skeleton for the new project.

diff --git a/greeter.py b/greeter.py
new file mode 100755
index 0000000..b96deee
--- /dev/null
+++ b/greeter.py
@@ -0,0 +1,6 @@
+#!/usr/bin/env python
+
[...]

Iniziamo a lavorarci (1)

Iniziamo a lavorare al progetto, riempiendo qualche file.

greeter/greeter.py:

class Greeter:
    """ """

    def greet(self):
        print "Hello World!"

Iniziamo a lavorarci (2)

greeter.py:

#!/usr/bin/env python

import greeter

def main():
    grt = greeter.Greeter()
    grt.greet()

if __name__ == '__main__': main()

Diamo in pasto a git

E vediamo di nuovo il workflow quotidiano: aggiungiamo le modifiche fatte alla staging area con git add per poi darle in pasto a git commit.

In questo caso anziché usare un editor per descrivere il commit ci accontentiamo di una descrizione breve, passata per comodità con l'opzione -m.

$ git add greeter.py greeter/greeter.py
$ git commit -m 'Generic greetings'
[master adfbc73] Generic greetings
 2 files changed, 8 insertions(+), 1 deletion(-)
$ git status
# On branch master
nothing to commit (working directory clean)
$ git log
commit adfbc7340ac1af8b1dc80ebb1526c7b2b9ad4d1f
Author: Elena ``of Valhalla'' Grandi <valhalla@trueelena.org>
Date:   Thu Nov 15 19:08:29 2012 +0100

    Generic greetings

commit b54e94fde972281ca31a56ef0d36204addd4906b
Author: Elena ``of Valhalla'' Grandi <valhalla@trueelena.org>
Date:   Thu Nov 15 19:05:42 2012 +0100

    Skeleton for the new project.

amend

Se ci si è accorti di aver sbagliato qualcosa nella descrizione del commit lo si può cambiare con git commit --amend.

$ git commit --amend
Generic greetings.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD^1 <file>..." to unstage)
#
#       modified:   greeter.py
#       modified:   greeter/greeter.py
[master 8cdccd9] Generic greetings.
 2 files changed, 8 insertions(+), 1 deletion(-)

Notare come l'identificativo del commit sia cambiato: di fatto git commit --amend cancella l'ultimo commit e ne crea uno nuovo.

Questo significa che questo comando non si può usare nel caso in cui si sia già distribuito in qualche modo il commit in questione, dato che la cosa può causare problemi negli altri repository.

gitignore

Lavorando al progetto capita che si generino file che si vogliono ignorare, ad esempio i risultati di compilazione: basta aggiungerli al file .gitignore perché non vengano considerati.

$ ./greeter.py
Hello World!
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       greeter/__init__.pyc
#       greeter/greeter.pyc
nothing added to commit but untracked files present (use "git add" to track)
$ echo "*.pyc" >> .gitignore
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .gitignore
nothing added to commit but untracked files present (use "git add" to track)
$ git add .gitignore
$ git commit -m '.gitignore: ignore .pyc files.'

Aggiungere funzionalità

Vogliamo aggiungere al nostro progetto la capacità di salutare persone diverse; dato che dobbiamo fare un po' di modifiche, perché non creare un nuovo feature branch?

Questo è il workflow naturale per git: ogni nuova funzionalità viene sviluppata a parte in un branch apposito, e poi integrata nel branch principale, che in questo modo rimane sempre funzionante.

$ git checkout -b people

greeter/greeter.py:

class Greeter:
    """ """

    def greet(self,greetee="World"):
        print "Hello %s!"%gretee
$ git add greeter/greeter.py

Che bel sole là fuori!

Anche se non abbiamo finito di implementare la nuova feature, ci accorgiamo che c'è un bel sole e vogliamo andare a lavorarci al parco (o dobbiamo correre a prendere il treno), e vogliamo spostarci a lavorare sul portatile.

Niente di più semplice: committiamo quel che abbiam fatto fin'ora, cloniamo il repository su una chiavetta usb, e possiamo lavorare dal portatile senza problemi.

$ git commit -m 'greeter/greeter.py: support for multiple greetees.'
$ cd $USB_KEY
$ git clone /home/[...]/greeter
Cloning into 'greeter'...
done.
$ cd greeter
$ git branch
* people
$ git branch -a
* people
  remotes/origin/HEAD -> origin/people
  remotes/origin/master
  remotes/origin/people

Con il comando git branch scopriamo che il clone ha già preso come branch corrente quello che stavamo usando sul primo repository, e con l'opzione -a possiamo vedere tutti i branch che abbiamo a disposizione.

Con git ogni copia comprende tutta la storia di tutti i branch disponibili nel repository che si è copiato, e quindi è possibile continuare a lavorare anche se ci si dovesse trovare senza connessione ad internet. Inoltre ogni clone del repository è un backup completo, utile nel caso in cui succeda qualcosa ad un hard disk.

Aggiunte successive (1)

Finiamo le modifiche di cui ci stavamo occupando, committiamo.

greeter.py:

#!/usr/bin/env python

import sys

import greeter

def main():
    grt = greeter.Greeter()
    try:
        grt.greet(sys.argv[1])
    except IndexError:
        grt.greet()

if __name__ == '__main__': main()

Aggiunte successive (1)

$ git add greeter.py
$ git commit -m 'greeter.py: support for a custom greetee.'
[people 59b9d39] greeter.py: support for a custom greetee.
 1 file changed. 6 insertions(+). 1 deletion(-)

Ora di rientrare (1)

Riattacchiamo la chiavetta al PC, cerchiamo di riportare le modifiche dal repository su chiavetta al repository su hard disk con il comando git push.

$ git push
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 487 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
remote: error: refusing to update checked out branch: refs/heads/people
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable t
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing int
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in som
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, se
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /home/[...]/greeter/
 ! [remote rejected] people -> people (branch is currently checked out)
error: failed to push some refs to '/home/[...]/greeter/'

Ora di rientrare (2)

C'è un problema: git non permette di fare push che dovrebbero modificare ciò che c'è nella working copy dell'altro repository; una soluzione sarebbe richiedere l'aggiornamento con il comando git pull dal repository sul PC, ma richiede un po' di configurazione. Per ora usiamo una soluzione veloce:

$ cd /home/[...]/greeter/
$ git checkout master
$ cd -
$USB_KEY/greeter
$ git push
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 487 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To /home/[...]/greeter/
   d78d340..59b9d39  people -> people
$ git log
commit 59b9d3971db8cb872c798b215365b22fb20aa5a7
[...]
$ cd /home/[...]/greeter/
$ git checkout people
Switched to branch 'people'
$ git  log
commit 59b9d3971db8cb872c798b215365b22fb20aa5a7

Bugfixing della versione stabile

Qualcuno ci fa notare che nella versione "stabile" del nostro programma c'è un errore: una riga di documentazione vuota. Rimediamo subito!

$ git checkout master
Switched to branch 'master'

greeter/greeter.py:

class Greeter:
    """This class greets people."""

    def greet(self):
        print "Hello World!"
$ git add greeter/greeter.py
$ git commit -m 'greeter/greeter.py: docstring for the class'
[master cdef61b] greeter/greeter.py: docstring for the class
 1 file changed, 1 insertion(+), 1 deletion(-)

Reintegriamo in master (1)

Adesso che la funzionalità è completa possiamo reintegrarla nel branch master: con gitk -a possiamo vedere la situazione attuale.

$ git checkout people
Switched to branch 'people'
$ gitk -a
images/gitk01.png

Notiamo che al momento il branch people parte da un commit di master che non è l'ultimo: questo non è un problema per riportarlo in master, ma causa un commit fittizio con il quale si descrive il merge.

Dato che il branch people non è stato pubblicato da nessuna parte, possiamo invece barare e portarlo a nascere dall'ultimo commit di master.

$ git log
commit 59b9d3971db8cb872c798b215365b22fb20aa5a7
[...]
commit d78d34010156781d20ef194a62f00d4eb9edb26b

Reintegriamo in master (2)

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: greeter/greeter.py: support for multiple greetees
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging greeter/greeter.py
Applying: greeter.py: support for a custom greetee.
$ git log
commit 5a23f44b8492f41f6a4834b959111b924efa905c
[...]
commit 2229a1833b2dd00922978140d5b7e16688408ee1
$ gitk -a
images/gitk02.png

I commit hanno cambiato identificativo, non sono più gli stessi di prima, ma almeno possiamo vedere che il nostro branch è la prosecuzione naturale di master.

Reintegriamo in master (3)

Già che ci siamo, però, possiamo decidere che i due commit riguardano la stessa modifica, per cui possiamo unirli in un commit solo.

$ git rebase -i master
pick 2229a18 greeter/greeter.py: support for multiple greetees
squash 5a23f44 greeter.py: support for a custom greetee.

# Rebase cdef61b..5a23f44 onto cdef61b
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Reintegriamo in master (3a)

Support for a custom greetee.
# This is a combination of 2 commits.
# The first commit's message is:

# This is the 2nd commit message:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:    Elena of Valhalla'' Grandi <valhalla@trueelena.org>
#
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   greeter.py
#       modified:   greeter/greeter.py
#

Reintegriamo in master (3b)

".git/COMMIT_EDITMSG" 18L, 509C written
[detached HEAD ca91dc9] Support for a custom greetee.
 Author: Elena of Valhalla'' Grandi <valhalla@trueelena.org>
 2 files changed, 8 insertions(+), 3 deletions(-)
Successfully rebased and updated refs/heads/people.

Reintegriamo in master (4)

A questo punto il nostro branch è pronto per essere reinserito in master.

$ git log
commit ca91dc9944e003ff47ec58464f3ebbb2ffdb8cfa
[...]
$ gitk -a
images/gitk03.png

Reintegriamo in master (5)

$ git checkout master
Switched to branch 'master'
$ git merge people
Updating cdef61b..ca91dc9
Fast-forward
 greeter.py         |    7 ++++++-
 greeter/greeter.py |    4 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)
$ git branch -d people
Deleted branch people (was ca91dc9).
$ gitk -a
images/gitk04.png

Un bel backup

Se abbiamo in casa un computer, magari sempre acceso, al quale possiamo accedere via ssh, possiamo usarlo come server su cui mettere un nostro repository "centrale" da usare per gestire il lavoro da più server diversi, ma anche come ulteriore copia di backup.

$ ssh $SERVER
$ mkdir -p git/greeter.git
$ cd git/greeter.git
$ git init --bare
Initialized empty Git repository in /home/[...]/git/greeter.git/
$ git remote add backup $SERVER:git/greeter.git
$ git push backup master
Counting objects: 23, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (23/23), 2.24 KiB, done.
Total 23 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (23/23), done.
To $SERVER:git/greeter.git/
 * [new branch]      master -> master

Finalmente pubblichiamo

$ $BROWSER http://gitorious.org
[...]
$ git remote add origin git@gitorious.org:greeter/greeter.git
$ git push -u origin master
Counting objects: 23, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (23/23), 2.24 KiB, done.
Total 23 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (23/23), done.
To git@gitorious.org:greeter/greeter.git
 * [new branch]      master -> master
   Branch master set up to track remote branch master from origin.

Non github?

Alternative:

Domande?