10. Repository remoti e collaborazione

10.1 Il modello del repository condiviso

Il modello più semplice: esiste un solo repository remoto (la “master copy”, la history ufficiale del progetto) raggiungibile da tutti i collaboratori. Ognuno:

• clona il repository (git clone) per avere la copia locale;
• invia i propri commit con git push;
• recupera i commit altrui con git fetch e git pull.

Il remote agisce anche da punto di sincronizzazione per branch e tag.

Cosa succede quando due collaboratori inviano commit in conflitto: supponiamo che partendo dalla stessa history (A-B-C) i due aggiungano localmente rispettivamente i commit D ed E. Quando il primo invia il proprio commit E al remote, il secondo non potrà più inviare D: per Git un commit non è solo una modifica ai file, ma uno snapshot dentro una sequenza. Le opzioni sono due:

1. recuperare la history aggiornata (A-B-C-E), integrarvi il proprio commit e inviare — opzione corretta;
2. forzare l’invio della propria history (A-B-C-D), cancellando ogni traccia del commit E dal remote — opzione da evitare: Git lo permette, ma la sovrascrittura della history va riservata a correzioni vere e proprie, non a vanificare il lavoro altrui.

10.2 git remote — gestire i remoti

Il comando non gestisce l’accesso effettivo ai server, ma i “segnalibri” (tracked repository) alle URL dei remoti:

git remote                      # elenca i remoti
git remote -v                   # elenca con URL (fetch e push)
git remote add john http://dev.example.com/john.git
git remote rename john same-origin
git remote rm same-origin

Convenzione: il remote originale di un clone si chiama origin; con più remoti è comune distinguere ad esempio origin (il proprio fork) e upstream (il progetto originale).

$ git remote -v
origin    https://github.com/developer/project-fork.git (fetch)
origin    https://github.com/developer/project-fork.git (push)
upstream  https://github.com/company/project.git (fetch)
upstream  https://github.com/company/project.git (push)

10.3 Piattaforme di hosting: GitHub, GitLab, Bitbucket

GitHub

GitHub è il servizio di hosting Git più diffuso: una piattaforma web che ospita repository remoti e aggiunge a Git un’interfaccia visiva e strumenti di collaborazione (issue, pull request, profili, integrazioni).

Git ≠ GitHub. Git è lo strumento di controllo versione che esegue le operazioni locali e di sync col server centrale; GitHub è la piattaforma che ospita il repository remoto e semplifica la collaborazione. Rispetto a un semplice file hosting in cloud (es. Dropbox), GitHub documenta e organizza le modifiche: se più persone lavorano allo stesso contenuto non c’è il problema di “chi salva per primo sovrascrive gli altri”.

Esempio di flusso completo dall’interfaccia web:

1. Creare il repository — iscrizione su github.com, poi “Nuovo progetto”. Si sceglie se il repository è pubblico (visibile a tutti) o privato (visibilità controllata) e si può inizializzarlo con un file README, che ne diventa il primo file.
2. Creare un branch — dal menu a tendina dei branch (es. su main) si cerca un branch esistente o se ne crea uno nuovo (es. readme-changes). Il nuovo branch parte come copia di main.
3. Modificare un file e committare — dal branch nuovo si apre il file, si clicca l’icona di modifica (la matita), si scrivono le modifiche nell’editor integrato e si salva con un messaggio di commit che descriva cosa è stato fatto (consigliato anche se non obbligatorio).
4. Aprire una pull request — dalla scheda “Pull request” si crea una nuova richiesta selezionando i due branch; GitHub mostra le differenze tra le versioni dei file. Si aggiunge titolo e descrizione e si crea la PR: da qui i collaboratori possono discutere e revisionare le modifiche.
5. Fare il merge — una volta approvata la PR, si clicca “Merge pull request” e si conferma. Se non ci sono conflitti, le modifiche finiscono nel branch principale; il branch usato per la feature può poi essere eliminato.

Per usare codice pubblico si può clonare con git clone (dal tasto verde “Code” del repository si copia l’URL) oppure scaricare direttamente l’archivio zip.

GitLab

Piattaforma DevOps completa: repository pubblici e privati gratuiti, issue tracking, wiki, CI/CD, sicurezza e monitoraggio. Le autorizzazioni si impostano una sola volta e valgono per tutti i componenti dell’organizzazione, riducendo i cicli di sviluppo e aumentando la produttività dei team.

Bitbucket

Hosting Git basato sul cloud, con interfaccia semplice adatta anche a chi è alle prime armi (usare Git “puro” richiede più dimestichezza con la riga di comando). Offre collaborazione tra team, test e deploy del codice; storicamente molto integrato con gli ecosistemi Atlassian.

10.4 Il modello Fork & Pull

Alternativa al repository condiviso, promossa da GitHub: esistono due remoti per ogni collaboratore.

• upstream: il repository originale, “master copy” del progetto — accessibile solo in lettura (fetch) ai collaboratori esterni;
• origin: un fork, cioè una copia personale del repository — accessibile sia in lettura che in scrittura.

Il flusso: si lavora sul proprio fork, si inviano i commit al fork, e si propone l’inclusione nel progetto originale tramite pull request; il maintainer può recuperare le modifiche dal fork con git pull. Allo stesso modo il proprietario del fork può aggiornarlo con i nuovi commit dell’upstream.

Questo modello è pensato per progetti (tipicamente open source) in cui non è desiderabile dare accesso in scrittura al repository principale a ogni sviluppatore.