Appunti su Git¶
Lo sviluppo di fuss viene gestito tramite repository git pubblicati sull’istanza gitlab https://gitlab.fuss.bz.it. Per le basi dell’uso di git si rimanda ai link presenti nella sezione Vedere anche, ma questo documento contiene indicazioni su come svolgere alcuni compiti specifici.
Indice
Branch per il supporto di più distribuzioni¶
Lo sviluppo nel branch master
si riferisce sempre alla distribuzione
più recente tra quelle supportate per quel pacchetto; qualora vengano
supportate anche distribuzioni più vecchie tale supporto avviene in un
branch chiamato con il nome della distribuzione (ad esempio buster
).
Avvertimento
In alcuni pacchetti il nome del branch è ancora nella forma
fuss/<distribuzione>
: questo è da evitare, perché conflitta con
il nome del branch usato per la pacchettizzazione in un branch
separato, ma ancora non è stato interamente uniformato.
Modifiche da applicare a tutte le distribuzioni¶
Nel caso in cui si debbano fare modifiche che devono essere presenti in
tutte le versioni, la buona pratica è di effettuare la modifica nella
versione più recente (branch master
), la si committi e quindi si
faccia il cherry pick del commit sul branch delle versioni più vecchie.
Ad esempio, essendo nella seguente situazione:
fuss-foo (master)$ git log --graph --abbrev-commit --pretty=oneline
* 7bc3fd2 (HEAD -> master) Start working on bullseye
* 0f46c37 (buster) Readme for the fuss-foo project
Si fa una modifica, la si committa con il comando:
fuss-foo (master)$ git commit -m 'Add project description.'
E ci si trova nella situazione seguente:
fuss-foo (master)$ git log --graph --abbrev-commit --pretty=oneline
* 36c12d2 (HEAD -> master) Add project description.
* 7bc3fd2 Start working on bullseye
* 0f46c37 (buster) Readme for the fuss-foo project
A questo punto passiamo sul branch della vecchia distribuzione, e
facciamo cherry-pick
del commit, ovvero lo copiamo nel nuovo
branch:
fuss-foo (master)$ git checkout buster
fuss-foo (buster)$ git cherry-pick 36c12d2
Auto-merging README.rst
CONFLICT (content): Merge conflict in README.rst
error: could not apply 36c12d2... Add project description.
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".
Purtroppo non è andato tutto bene e la modifica non si applica in modo
pulito; apriamo il file README.rst
e troviamo quanto segue:
Fuss FOO
========
<<<<<<< HEAD
This is FOO for buster
=======
This is FOO for bullseye
It is an example project.
>>>>>>> 36c12d2 (Add project description.)
risolviamo il conflitto manualmente, portando i contenuti ad essere:
Fuss FOO
========
This is FOO for buster
It is an example project.
e infine proseguiamo il cherry-pick
come suggerito dal messaggio di
errore:
fuss-foo (buster)$ git add README.rst
fuss-foo (buster)$ git cherry-pick --continue
[...]
[buster c21a51e] Add project description.
Date: Fri Jun 10 11:03:35 2022 +0200
1 file changed, 2 insertions(+)
Confermando il messaggio di commit nell’editor che si è aperto.
A questo punto la situazione è diventata:
fuss-foo (buster)$ git log --graph --abbrev-commit --pretty=oneline --all
* c21a51e (HEAD -> buster) Add project description.
| * 36c12d2 (master) Add project description.
| * 7bc3fd2 Start working on bullseye
|/
* 0f46c37 Readme for the fuss-foo project
che è quanto desideravamo.
Nota
Nella maggior parte dei casi git è abbastanza furbo ed è raro
trovarsi nella situazione sopra in cui il cherry-pick richiede
intervento manuale per risolvere conflitti, tranne che in un caso
specifico: il file debian/changelog
.
Se si tiene la pacchettizzazione debian dentro ad un branch separato questo non è un problema, ma se si ha ancora la pacchettizzazione assieme al codice, ci si trova in una situazione in cui non c’è una buona soluzione.
Se si mettono le modifiche a debian/changelog
nello stesso commit
in cui le modifiche sono state fatte si ottiene una storia del
repository più pulita, ma si ha la certezza di trovare a dover
risolvere un conflitto in fase di cherry-pick.
Committare invece debian/changelog
a parte previene quei
conflitti, ma lascia una storia più sporca, con almeno due commit per
ciascuna modifica: non è un gran problema quando ad una riga di
changelog corrispondono magari una decina di commit di uno sviluppo
importante, ma quando una riga di changelog corrisponde ad un solo
semplice commit, come spesso è il caso, può essere fastidioso.
Vedere anche¶
- Pro Git di Scott Chacon libro consultabile online.
- Git Happens di Jessica Kerr video di un talk introduttivo a git.