Come installare Git su CentOS 7 passo dopo passo

Su CentOS 7 Git si installa senza stranezze se parti dal pacchetto gestito dal sistema e non da binari scaricati a mano. In pratica la sequenza corretta è: controlli cosa c’è già, installi dal repository disponibile, verifichi la versione e solo dopo valuti se servono repository aggiuntivi o una build da sorgente. Su un server questo approccio riduce il rumore operativo, lascia traccia nel gestore pacchetti e rende più semplice un eventuale rollback.

Il punto non è “installare Git” e basta, ma farlo in modo coerente con una macchina CentOS 7, che è stabile ma spesso ferma a versioni meno recenti. Quindi conviene distinguere subito tra esigenza base, necessità di una release più nuova e casi in cui il pacchetto standard non è presente perché manca un repository utile come EPEL.

Installare Git dai repository di CentOS 7

Prima di modificare qualcosa, verifica se Git è già presente. Su un host usato da più persone o da automazioni è una verifica banale ma utile: ti dice se stai installando da zero, se devi aggiornare o se il problema è solo di PATH.

rpm -q git

Se Git non è installato, l’output tipico è package git is not installed. Se invece è già presente, vedrai la versione installata. Questo dettaglio conta perché su CentOS 7 potresti trovarti con una release vecchia ma funzionante, e non sempre ha senso sostituirla se il tuo uso è solo clone, commit e push verso repository remoti.

Per installarlo dai repository standard, aggiorna prima la cache e poi procedi con yum:

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

L’installazione con yum è la scelta più pulita su questa piattaforma perché gestisce dipendenze e aggiornamenti in modo coerente con il resto del sistema. Se stai operando su una macchina di produzione, puoi togliere -y per leggere l’elenco dei pacchetti coinvolti prima di confermare.

Dopo l’installazione, verifica che l’eseguibile sia disponibile e che la versione risponda correttamente:

which git
git --version

L’output atteso è un percorso come /usr/bin/git e una stringa del tipo git version 1.8.3.1 o simile, a seconda degli aggiornamenti presenti nei repository del sistema.

Capire la versione disponibile su CentOS 7

CentOS 7 ha un ciclo di vita e un livello di stabilità che si riflettono direttamente sui pacchetti. Git nei repository base può essere più datato rispetto a quello che trovi su distribuzioni più recenti, e questa non è una sorpresa: è il comportamento normale di una piattaforma conservativa.

Per attività classiche come gestire repository, fare commit locali e lavorare con rami semplici, la versione di sistema spesso basta. Se invece ti servono opzioni introdotte in release più nuove, la sola installazione standard potrebbe non essere sufficiente. In quel caso devi decidere se la versione del repository è accettabile oppure se serve una fonte più aggiornata.

Un controllo rapido della versione installata ti aiuta a prendere questa decisione senza andare a tentativi:

git --version

Se il numero di versione è troppo vecchio rispetto alle esigenze del tuo progetto, il problema non è l’installazione in sé ma la compatibilità tra il workflow richiesto e il parco pacchetti disponibile su CentOS 7.

Abilitare EPEL quando il repository base non basta

In molti scenari Git è già disponibile nei repository standard, quindi EPEL non è un prerequisito automatico. Però su alcuni sistemi il repository aggiuntivo può aiutare a risolvere pacchetti correlati o a sbloccare dipendenze che altrimenti mancano. La regola pratica è semplice: lo abiliti solo se serve, non per abitudine.

Controlla prima se epel-release è già presente:

rpm -q epel-release

Se non è installato e hai motivo di usarlo, aggiungilo con il gestore pacchetti:

sudo yum install -y epel-release

Poi aggiorna la cache e riprova l’installazione o la verifica dei pacchetti:

sudo yum makecache
sudo yum install -y git

Se Git era già disponibile nei repository base, EPEL non cambia nulla per questo pacchetto. Se invece il repository standard non era sufficiente, l’abilitazione di EPEL può risolvere il problema senza costringerti a installazioni manuali fuori controllo.

Configurazione iniziale dopo l’installazione

Installare Git è solo il primo passo. Su una macchina usata per lavoro conviene impostare subito identità e comportamento base, altrimenti i commit rischiano di avere metadati incompleti o incoerenti. Questo è ancora più importante se il server viene usato da più operatori o da account di servizio.

Imposta nome ed email dell’utente che userà Git:

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

Verifica la configurazione salvata:

git config --global --list

Le impostazioni globali finiscono nel file ~/.gitconfig dell’utente che ha eseguito il comando. È il punto da controllare se qualcosa non torna, e anche il punto da tenere presente se devi replicare la stessa configurazione su un altro server.

Su host condivisi evita di impostare questi valori a livello di root se Git deve essere usato da un account applicativo separato. La configurazione globale deve appartenere all’identità che effettivamente lavora con repository e commit.

Installare Git da sorgente quando serve una versione più nuova

La compilazione da sorgente non è la strada normale, ma diventa sensata quando il pacchetto dei repository è troppo vecchio rispetto alle funzionalità richieste. In quel caso conviene essere disciplinati: installi prima le dipendenze, poi scarichi una release ufficiale, compili in modo esplicito e tieni traccia del percorso usato.

Prima installa gli strumenti di compilazione e le librerie più comuni:

sudo yum groupinstall -y "Development Tools"
sudo yum install -y curl-devel expat-devel gettext-devel openssl-devel perl-CPAN perl-devel zlib-devel

Questi pacchetti servono a soddisfare i prerequisiti tipici della build di Git su sistemi legacy. Se manca una dipendenza, la compilazione si interrompe subito: meglio verificarlo prima che arrivare a metà processo senza sapere cosa manca.

Scarica poi una release ufficiale da una fonte attendibile e scompattala in una directory di lavoro dedicata:

tar -xzf git-*.tar.gz
cd git-*

Compila e installa in modo controllato:

make prefix=/usr/local all
sudo make prefix=/usr/local install

Con questo metodo l’eseguibile finisce in genere in /usr/local/bin/git. A quel punto è fondamentale verificare quale binario viene risolto per primo nel PATH:

which git
git --version

Se il sistema continua a mostrare la versione vecchia, il problema non è la compilazione ma l’ordine delle directory nel PATH dell’utente. In quel caso va controllato l’ambiente della shell o i profili utente, non rifatta la build a caso.

Pacchetto RPM o build manuale: come scegliere

Nella maggior parte dei casi su CentOS 7 conviene restare sul pacchetto RPM. È più facile da mantenere, si aggiorna insieme al sistema e si rimuove senza lasciare residui sparsi. Questo vale soprattutto su macchine condivise, nodi di automazione e server che ricevono patch regolari.

La build manuale ha senso solo se hai un requisito preciso sulla versione o su una funzionalità non presente nei repository. In quel caso però devi accettare un costo operativo maggiore: aggiornamenti fuori dal flusso standard, documentazione della procedura e attenzione al rollback.

Una regola pratica utile è questa: se ti serve Git per operazioni normali, usa l’RPM. Se ti serve una release specifica per un flusso CI, per una feature recente o per compatibilità con un tool esterno, la compilazione da sorgente è accettabile, ma solo se la tieni tracciata.

Verifiche finali e rollback minimo

Dopo l’installazione fai sempre tre controlli: presenza del pacchetto, versione effettiva e configurazione utente. Sono verifiche rapide ma evitano di scoprire un problema solo al primo clone o al primo commit.

rpm -q git
git --version
git config --global --list

Se hai installato da repository, il rollback è semplice: rimuovi il pacchetto con il gestore standard e, se necessario, disabilita il repository aggiuntivo che hai abilitato solo per il test. Se invece hai compilato da sorgente, il rollback dipende dal prefisso usato: con /usr/local devi rimuovere i file installati in quel percorso e ripristinare l’eventuale binario RPM precedente.

Se vuoi essere rigoroso, conserva il comando usato per l’installazione e il percorso dell’eseguibile effettivamente in uso. In questo modo sai sempre cosa stai rimuovendo o aggiornando senza confondere la build manuale con il pacchetto di sistema.

Assunzione: il sistema ha connettività verso i mirror yum e il repository base di CentOS 7 è raggiungibile; se il pacchetto non compare, il primo punto da chiudere è la disponibilità dei repository, non Git in sé.