Come installare Git su CentOS 7 passo dopo passo

Su CentOS 7 Git si installa in modo semplice, ma conviene farlo con un criterio preciso: prima verificare la versione disponibile nei repository, poi installare il pacchetto corretto e infine controllare che il binario risponda come atteso. In ambienti server non serve solo “avere git”: serve sapere da dove arriva, quale versione stai usando e come mantenerlo aggiornato senza introdurre sorprese.

CentOS 7 resta comune su macchine legacy, host di build, ambienti di staging e server applicativi che non sono ancora stati migrati. In questi contesti Git viene usato per distribuire codice, gestire playbook, versionare configurazioni e fare checkout di applicazioni web. L’installazione è banale; il punto vero è evitare di fermarsi al comando di copia-incolla senza controllare repository, permessi e compatibilità con il resto del sistema.

Verificare lo stato del sistema prima di installare Git

Prima di toccare il sistema, controlla che il nodo sia effettivamente CentOS 7 e che i repository base siano raggiungibili. Se il server è dietro proxy, in rete isolata o con mirror interni, questo passaggio ti evita installazioni fallite o versioni inattese.

Usa questi comandi per capire rapidamente il contesto:

cat /etc/centos-release
yum repolist
uname -r

Il primo comando conferma la release, il secondo mostra i repository abilitati, il terzo è utile solo per un controllo generale del kernel e non influisce direttamente su Git. Se yum repolist restituisce errori di DNS, mirror non raggiungibili o repository vuoti, risolvi prima quello: installare pacchetti in un sistema che non vede i repository è solo tempo perso.

Se vuoi essere ancora più preciso, verifica la presenza del pacchetto senza installarlo subito:

yum info git

Se il comando restituisce metadati del pacchetto, il repository è in ordine. Se invece non trova nulla, il problema non è Git ma la configurazione dei repository o la connettività verso gli spec file.

Installazione standard con yum

Nel caso più comune, Git si installa dal repository base di CentOS con un solo comando. È la strada giusta quando non hai esigenze specifiche di versione e vuoi mantenere il sistema allineato ai pacchetti supportati dalla distribuzione.

sudo yum install -y git

Il flag -y evita la conferma interattiva, utile in provisioning o in sessioni amministrative controllate. Se preferisci un approccio più prudente, puoi ometterlo e leggere il riepilogo dei pacchetti coinvolti prima di accettare.

Durante l’installazione, yum scarica il pacchetto e le eventuali dipendenze. Su CentOS 7 Git non porta in genere un albero di dipendenze pesante, quindi l’operazione è veloce e poco invasiva. Se l’installazione fallisce, il motivo più frequente è uno tra questi: repository non disponibili, cache metadata corrotta, spazio disco insufficiente o problemi di rete verso i mirror.

Per ridurre il rumore e capire subito cosa sta succedendo, puoi forzare l’aggiornamento della cache e rilanciare il tentativo:

sudo yum clean all
sudo yum makecache
sudo yum install -y git

Questo non altera la configurazione del sistema, ma ti dice se il problema è temporaneo o strutturale. Se makecache fallisce, il problema è a monte: rete, DNS, proxy o repository upstream.

Controllare la versione installata

Dopo l’installazione non basta vedere che il pacchetto sia presente. Devi verificare il binario effettivamente usato dal sistema e la versione pubblicata dal comando.

git --version
which git
rpm -q git

Il primo comando mostra la versione, il secondo ti dice quale eseguibile viene richiamato, il terzo conferma il pacchetto RPM installato. Su sistemi con più toolchain o installazioni manuali in /usr/local/bin, which git è importante perché evita di confondere il pacchetto di sistema con un binario custom.

Un output tipico potrebbe essere:

git version 1.8.3.1
/usr/bin/git
git-1.8.3.1-25.el7_9.x86_64

Su CentOS 7 la versione del repository base è datata rispetto agli standard moderni, ma spesso è sufficiente per deployment classici, automazioni e gestione repository interni. Se ti serve una versione più recente per funzionalità specifiche, la domanda non è più “come installo Git”, ma “da quale repository lo prendo senza rompere il resto del sistema”.

Quando la versione del repository non basta

In alcune installazioni la versione base di Git è troppo vecchia per il flusso di lavoro richiesto. Succede con feature come partial clone, opzioni di sicurezza più recenti, integrazione con tool moderni o compatibilità con pipeline CI che pretendono un client aggiornato.

Qui ci sono due strade: abilitare un repository esterno affidabile oppure compilare da sorgente. La prima è quasi sempre la scelta migliore in produzione o in ambienti gestiti, perché mantiene tracciabilità e aggiornamenti tramite package manager. La seconda ha senso solo se hai un motivo tecnico forte e un processo chiaro per manutenzione e rollback.

Se usi repository esterni, il punto critico è la fiducia nella sorgente. Devi sapere chi mantiene il repo, con quale frequenza aggiorna i pacchetti e se esiste una policy di firma. Non è un dettaglio: su una macchina server, aggiungere un repository equivale ad ampliare la superficie di supply chain.

Un approccio prudente è verificare i repository disponibili e leggere il file di configurazione prima di abilitarne uno nuovo:

ls -1 /etc/yum.repos.d/
cat /etc/yum.repos.d/*.repo

Così vedi subito cosa è già presente e come sono impostati baseurl, mirrorlist, gpgcheck e priority. Se devi installare Git da un repository aggiuntivo, conserva una copia del file repo prima della modifica:

sudo cp /etc/yum.repos.d/NOME.repo /etc/yum.repos.d/NOME.repo.bak

Questo ti dà un rollback immediato e pulito, soprattutto se il repo esterno causa conflitti di dipendenze o sostituzioni non previste.

Installazione da repository aggiuntivi: quando ha senso

Su CentOS 7 una pratica frequente è usare un repository di terze parti affidabile per ottenere una versione più recente di Git. Il vantaggio è evidente: pacchetto gestito da RPM, aggiornamenti centralizzati e rimozione semplice. Lo svantaggio è altrettanto evidente: stai delegando una parte della catena di fiducia a un soggetto esterno.

Prima di procedere, controlla se il repository è già presente e se il pacchetto che cerchi è esposto correttamente:

yum repolist enabled
yum list available | grep -i '^git\.'

Se il pacchetto appare con un nome diverso, ad esempio versione prefissata o pacchetto da repository specifico, annotalo prima di installare. È facile sbagliare nome e finire su un pacchetto non desiderato, soprattutto quando più repository forniscono lo stesso software con naming simile.

Una volta identificato il pacchetto giusto, la logica resta la stessa:

sudo yum install -y NOME_PACCHETTO

Dopo l’installazione, ricontrolla sempre il binario effettivo con which git e la versione con git --version. Se il sistema continua a mostrare una versione vecchia, potresti avere un binario precedente in /usr/local/bin o in un altro path prioritario.

Compilare Git da sorgente: solo se serve davvero

La compilazione da sorgente è l’ultima opzione, non la prima. Serve quando hai vincoli di versione, vuoi un build custom o lavori in ambienti in cui i repository disponibili non sono accettabili. Però introduce manutenzione manuale: dipendenze di build, path di installazione, aggiornamenti fuori dal ciclo RPM e rollback più laboriosi.

Se devi andare su questa strada, separa bene il piano di build dal piano di produzione. Installa i pacchetti di sviluppo necessari, scarica il sorgente da una sorgente affidabile e conserva checksum o firma quando disponibili. In questo modo puoi ricostruire lo stesso binario in futuro e non dipendere da un archivio “visto una volta e mai più”.

Una sequenza minima, a livello concettuale, è questa:

sudo yum groupinstall -y "Development Tools"
sudo yum install -y curl-devel expat-devel gettext-devel openssl-devel perl-devel zlib-devel
# scaricare il sorgente da fonte attendibile
# compilare e installare secondo le istruzioni della release

Qui il rischio operativo è maggiore: puoi sovrascrivere file di sistema o finire con due installazioni concorrenti. Per questo, se possibile, preferisci installazione in un prefisso controllato e documenta il path nel tuo inventario. Non usare la compilazione come scorciatoia per “avere l’ultima versione” su un server che deve restare semplice da mantenere.

Configurazione iniziale dopo l’installazione

Una volta installato Git, il passo successivo è impostare l’identità dell’utente che lo userà. Su server condivisi o host di automazione questo è importante: il commit deve avere autore e mail coerenti con il contesto operativo, altrimenti perdi tracciabilità.

git config --global user.name "Nome Cognome"
git config --global user.email "utente@example.com"

Se il server è multiutente o usato solo per un servizio applicativo, valuta se il parametro debba essere impostato globalmente o solo a livello di repository. In ambienti dove più account condividono la stessa macchina, il globale può essere troppo largo. In quel caso conviene lavorare dentro il repository o sotto l’utente corretto del servizio.

Controlla poi la configurazione effettiva:

git config --list --show-origin

Questo comando è molto utile perché mostra non solo i valori, ma anche il file da cui provengono. Se qualcosa non torna, puoi vedere subito se l’impostazione arriva da /etc/gitconfig, da ~/.gitconfig o dal repository locale.

Verifiche operative in un caso reale

Il controllo più concreto è fare un clone di test da un repository noto e vedere se il flusso funziona dall’inizio alla fine. Non serve un repository enorme: basta un remote accessibile e coerente con il tuo scenario reale, ad esempio GitHub, GitLab o un server interno.

git clone https://example.com/repo.git
cd repo
git status

Se il clone riesce e git status non segnala anomalie, il client è operativo. Se fallisce, il messaggio d’errore ti dice spesso dove guardare: certificati TLS, proxy aziendale, DNS, credenziali o firewall in uscita.

In ambienti chiusi, un errore comune è la mancanza di accesso HTTPS verso l’esterno. In quel caso non è Git a essere rotto: è la rete o la policy di egress. Se lavori con repository interni, testa direttamente il dominio interno invece di usare endpoint pubblici che non rappresentano il tuo caso d’uso.

Problemi tipici e come leggerli velocemente

Se git non viene trovato dopo l’installazione, il primo controllo è il path. Su sistemi dove qualcuno ha già installato tool custom, il binario di sistema può essere presente ma non prioritario nella variabile PATH.

echo $PATH
ls -l /usr/bin/git /usr/local/bin/git

Se il pacchetto risulta installato ma il comando fallisce, hai quasi certamente un problema di path o di alias. Se invece rpm -q git restituisce il pacchetto ma git --version mostra altro, allora c’è un binario diverso che precede quello RPM.

Se yum install fallisce con errori di metadata, prova la cache. Se fallisce con errori di connessione, prova a verificare DNS e routing verso il mirror. Se fallisce per spazio insufficiente, controlla immediatamente la partizione di sistema:

df -h
journalctl -xe

Su macchine vecchie o molto piene, un semplice yum install può bloccarsi perché /var o / non hanno abbastanza spazio per cache e RPM temporanei. In quel caso la correzione non è “riprovare”, ma liberare spazio in modo controllato oppure spostare la cache su un volume adeguato.

Disinstallazione pulita e rollback

Se hai installato Git dal repository standard e devi tornare indietro, la rimozione è semplice. Prima però verifica se qualche script, pipeline o servizio dipende da quel binario. La disinstallazione di un tool di base può rompere automazioni che non sono immediatamente visibili.

sudo yum remove -y git

Prima di eseguire il rollback, valuta il blast radius: repository locali, script di deploy, job cron, hook di sistema, playbook e tool di amministrazione che usano Git in modo implicito. Dopo la rimozione, controlla che il comando non sia più disponibile e che non restino binari alternativi in path non standard:

which git
rpm -q git

Se hai aggiunto repository esterni solo per Git, rimuovi anche la configurazione del repository o disabilitala, ma fallo solo dopo aver verificato che non serva ad altri pacchetti. In ambienti gestiti è meglio documentare il cambiamento e mantenere una copia del file repo originale per un eventuale ripristino.

Scelta pratica consigliata su CentOS 7

Se non hai vincoli particolari, la scelta corretta è installare Git dal repository standard con yum, verificarne la versione e usare quella. È il percorso più pulito, più facile da mantenere e più prevedibile in caso di assistenza o audit.

Se la versione base non basta, passa a un repository affidabile e documenta il motivo tecnico del cambio. La compilazione da sorgente va tenuta come eccezione, non come pratica standard. Su CentOS 7 il costo vero non è installare Git: è mantenerlo in modo che tra sei mesi il sistema sia ancora leggibile, aggiornabile e reversibile.

Assunzione: il server è un host CentOS 7 con accesso a repository yum funzionanti e senza vincoli di hardening che impediscano l’uso del package manager.