Guide per aspiranti programmatori

Il comando git push in Git serve a fare l’upload delle modifiche locali su un repository remoto. In questo modo, i commit locali sono resi disponibili agli altri collaboratori del progetto, che potranno recuperarli tramite un fetch e incorporarli nei rispettivi repository locali.

Nella modalità standard, git push invia solo le nuove modifiche, poiché Git sa quali commit sono già presenti nel repository remoto.

$ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commit.
(use "git push" to publish your local commits)

$ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 16 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 612 bytes | 612.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://server.com/project.git
e953fe1..cf9735f main -> main

Prima e dopo il push

Eseguendo git push senza indicare argomenti, verranno inviate al repository remoto collegato al branch attualmente in uso nella propria working copy locale solo i nuovi commit.

È possibile, comunque, indicare vari argomenti al comando per scegliere cosa esattamente inviare al repository remoto.

$ git tag v1.2.3

$ git push --tags
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://server.com/projecto.git
* [new tag]     v1.2.3 -> v1.2.3

Il push di tag verso un repository remoto deve essere esplicitamente indicato attraverso l’argomento –tags, che invia tutti i nuovi tag presenti sul repository locale al repository remoto.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

$ git branch new-feature

$ git branch
* main
 new-feature

$ git push --all
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://server.com/projecto.git
* [new branch]   new-feature -> new-feature

Con l’argomento –all invece viene fatto l’upload di tutti i branch presenti nel repository locale verso il repository remoto.

$ git remote -vv
backup  git@gitlab.com:elle.uca/aulab-demo.git (fetch)
backup  git@gitlab.com:elle.uca/aulab-demo.git (push)
origin  https://github.com/elleuca/aulab-demo.git (fetch)
origin  https://github.com/elleuca/aulab-demo.git (push)

$ git status
On branch main
Your branch is up to date with 'origin/main'.

$ git branch -vv
* main 35aad79 [origin/main] Initial commit

$ git push backup
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 642 bytes | 642.00 KiB/s, done.
Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
To gitlab.com:elle.uca/aulab-demo.git
* [new branch]   main -> main

È, ovviamente, possibile indicare, nel caso in cui si abbiano più repository remote e più branch, il branch specifico da inviare e il remote a cui inviarlo eseguendo il comando nella forma git push <remote> <branch>.

Per completezza e per non essere colti impreparati nel caso di necessità, vediamo come agire nel caso in cui sia necessario cambiare la history dopo che abbiamo già effettuato il push sul repository remoto. 

Ad esempio, supponiamo di essere nella situazione in cui vogliamo effettuare un commit che modifica un file preesistente e ne aggiunge un altro, necessario affinché la modifica apportata al nostro progetto abbia senso. Per errore, però abbiamo incluso nel commit solo il file con le modifiche.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
 modified:  page.html

Untracked files:
 public/new-logo.png

$ git commit -m "update logo" && git push
[main d5c0b92] update logo

Poiché, in realtà, il commit non rappresenta l’effettiva modifica voluta, potrebbe essere utile effettuare l’amend del commit invece di aggiungere un secondo commit. 

In questo modo, però, la history del repository locale cambia rispetto a quella repository remoto (con l’amend, infatti, in pratica sostituiamo uno snapshot con un altro snapshot). Per allineare repository locale e repository remoto possiamo effettuare il push con l’argomento –force.

$ git add public/new-logo.png

$ git commit --amend --no-edit
[main 5fb65cb] update logo

$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.
 (use "git pull" to merge the remote branch into yours)

$ git push --force
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 16 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 39.00 KiB | 19.50 MiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://server.com/projecto.git
+ 7b82870...5fb65cb main -> main (forced update)

È necessario essere estremamente attenti nell’uso dell’argomento –force del comando git push poiché, in questo caso, Git da per assunto che sia precisa intenzione dell’utente sovrascrivere interamente la history del branch remoto, sostituendola con quella del branch locale. Non è da escludere, infatti, che tra il nostro primo push e il secondo qualche altro collaboratore del progetto non abbia a sua volta effettuato altri push.

Per minimizzare perdite indesiderate, è sempre utile:

• effettuare il fetch e pull delle modifiche remote sul proprio branch locale prima di fare un push con force
• utilizzare –-force-with-lease invece di –force: in questo modo viene usata una modalità speciale del push con force che, nella pratica, avvisa nel caso si stia per rimuovere dal repository remoto commit altrui (che potranno quindi essere riportati nella copia locale prima di riprovare)