Se desideri impostare il controllo del codice sorgente per un progetto, ma preferisci di no per ospitarlo su un servizio come GitHub, puoi eseguire il tuo server git su un VPS per archiviare il tuo codice e fungere da repository principale per eventuali collaboratori.
Perché eseguire il tuo server?
Con quanti provider git hosted gratuiti ci sono, come GitHub, GitLab e Bitbucket, non ha molto senso farlo da soli. Ma ci sono alcune situazioni in cui è una soluzione praticabile.
Prima di tutto, eseguire il proprio server è molto più privato, soprattutto se si sta lavorando su codice che si preferisce non memorizzare sul “cloud di qualcun altro.” Questo non vuol dire che provider come GitLab non siano sicuri, ma ospitare tutto da soli può dare ad alcune persone più tranquillità.
Inoltre, se stai utilizzando un terzo- servizio party, ci sono restrizioni sulla dimensione del file che potrebbero non essere l'ideale. GitHub non consente file superiori a 100 MB, il che può essere un grosso problema per i progetti con file binari di grandi dimensioni. L'utilizzo del tuo server rimuove questo limite, supponendo che tu possa pagare per più spazio sul disco rigido.
Qualunque sia il tuo caso d'uso, probabilmente puoi fare di meglio di barebone git. La Community Edition di GitLab è gratuita e open source ed è facile da configurare sul tuo server. Questo ti dà tutti i vantaggi di ospitarlo da solo insieme a un'interfaccia web molto bella e numerosi strumenti CI/CD. Ti consigliamo vivamente di utilizzare GitLab se hai spazio libero sul server. (Richiede circa 3 GB di RAM.) Puoi leggere la nostra guida all'installazione e alla configurazione per saperne di più.
Pubblicità
Ma se non vuoi tutte le campane e i fischietti e vuoi solo eseguire un semplice telecomando git, puoi continuare a leggere.
I telecomandi Git sono solo il repository di qualcun altro
La prima cosa da notare su git è che l'hosting di un server non è in realtà molto complicato. Git utilizza un modello di controllo del codice sorgente distribuito; il tuo clone locale di un repository non si connette affatto a tutti i tuoi colleghi, ma si connette a un “remoto,” solitamente su un server o servizio centrale esterno. Quando si spinge e si tira, si apportano modifiche alla copia principale ufficiale del telecomando. Quando i tuoi colleghi recuperano dal telecomando, scaricano i tuoi commit.
Tecnicamente puoi eseguire git come servizio completamente decentralizzato. Se avessi due persone, ognuna estrae gli aggiornamenti l'una dall'altra. (In questa configurazione non è consigliabile eseguire il push su repository non server.) Questo non è realmente utilizzabile in pratica, a meno che entrambe le parti non abbiano indirizzi IP statici e siano sempre online, quindi la maggior parte delle persone opta per il client server model.
Quindi, tutto ciò che è un server git è solo un normale repository configurato come copia principale e aperto a Internet. È sorprendentemente semplice da configurare. Innanzitutto, dobbiamo creare un nuovo utente. Git utilizza SSH per l'autenticazione e tutto il traffico tra server e client, quindi avremo bisogno di un utente del servizio per gestire il repository.
sudo useradd git
Quindi, passa all'utente git per il resto della configurazione:
su git
Devi aggiungere le tue chiavi SSH al file authorized_keys dell'utente git:
nano ~/.ssh/authorized_keys Annuncio
Questa è un'area in cui servizi come GitHub e GitLab hanno la riga di comando Git beat. La gestione degli accessi non è facilmente gestibile in questo modo, poiché dovrai concedere a tutti l'accesso allo stesso utente del servizio, il che non è l'ideale, oppure dovrai impostare utenti separati per ogni persona, il che non è l'ideale. In entrambi i casi, i commit verranno visualizzati con qualsiasi nome utente ed email che l'utente finale ha configurato nelle sue impostazioni git.
Comunque, per creare il repository effettivo, esegui semplicemente git init nella home page dell'utente git. directory:
git init –bare repository.git
L'opzione –bare è necessaria qui. Di solito, quando cloni un repository, git memorizza tutti i file che utilizza per gestire le versioni nella cartella .git nascosta e mantiene una versione utilizzabile del luogo in cui si trova l'HEAD attualmente estratto. Questo di solito rende la tua cartella repo circa il doppio di quella che sarebbe senza git, anche se può essere più grande se hai file binari di grandi dimensioni e molte modifiche nel tempo.
Un repository nudo è semplicemente un repository senza le versioni utilizzabili dei file attualmente estratti. Invece, la cartella del repository è solo il contenuto di quella che sarebbe la cartella .git. Ciò consente di risparmiare spazio di archiviazione e configura il repository come server principale. Poiché non c'è contenuto locale, non ci saranno conflitti con il ramo HEAD. È una convenzione denominare i repository nudi con l'estensione di file .git, ma non è esplicitamente richiesto.
Questo è tutto ciò che è richiesto sul lato server. Dal tuo computer locale, dovrai clonare il repository o aggiungere un nuovo remoto:
git remote add origin git@example.com:repository.git
L'URL inizia con git@ perché è 8217; si connette su SSH come utente git. Il :repository.git alla fine è in realtà un nome di percorso, non solo un identificatore. Il percorso è relativo alla directory home dell'utente git, quindi se hai posizionato il repository da qualche altra parte, ti consigliamo di spostarlo qui o utilizzare il percorso completo.
Annuncio
Dopo aver connesso il repository locale, dovresti avere pieno accesso a push e pull come di consueto. Tieni presente che git predefinito non ha un sistema di autorizzazioni integrato, quindi non c'è nulla che impedisca a chiunque abbia accesso all'utente git di avere il pieno controllo sul tuo repository principale.