CSharp:Source Control - Git Server

Git remote Server

Con Git ci sono 2 possibilità su come conservare il proprio codice sorgente:

• in remoto (sul Cloud GitHub o proprio server, self-hosted, con diverse possibilità), argomento qui trattato;
• oppure in Locale.

Breve premessa.
Esiste una soluzione self-hosted, "chiavi in mano" di GitHub come alternativa alla versione Cloud, si chiama "GitHub Enterprise Server", per info: github.com GitHub for enterprises (soluzione qui non descritta).

Nei prossimi paragrafi si descriverà come configurare un Windows Git server centralizzato verso cui far convergere il controllo dei progetti degli sviluppatori che collaborano su diversi progetti (Git on the Server).
NOTA
Git non è nato per avere una gestione centralizzata ma distribuita quindi con più client ogiuno con una versione iniziale e modificata che poi potrà convergere e mischiarsi con le altre. Invece, ad es. in aziende in cui i dipendenti possono essere dislocati non in unico posto fisico può essere necessario che ci sia un server che faccia da repository condiviso e gestito\protetto centralmente.
Nella soluzione che qui si descriverà, si userà IIS ed il protocollo HTTP come tramite per intercettare le richieste dai client sull'archivio Git (gestito centralmente sul server). (Ci sono altre solizioni alternative a IS e basate su altri protocolli come Local FS, Secure Shell (SSH) e Git). Versione originale di questa guida tradotta è qui: smalltech.com.au
Alcune versioni alternative chiavi in mano:

• .Net BonoboGitServer
• Java BitBucket, Video tutorial Youtube

1. Installazione di GIT

Git (mentre si scrive abbiamo la ver 2.44.0) per Windows scaricabile qui: git-scm.com. Doc: BookAl termine saranno disponibili le seguenti app.

Qui si fa riferimento all'uso di Git CMD.

2. Creare la cartella di Repository

Si crea la cartella sul FileSystem, ad es., D:\Git_Repository
Ogni progetto sarà una cartella sotto la precedente.
Se si configurerà IIS, al punto 6, per interfacciarsi con Git usando una "Applicazione Web", la root repository fisica dei progetti ospitati su Git sarà una sottocartella ovvero D:\Git_Repository\Git_IIS dove "Git_IIS" è il nome della Applicazione Web che installeremo al punto 6.

3. Creare utenti del servizio Git

Utenti locali al Server

Si crea uno "Standard User" di test, ad es. GitUser1 da utilizzare da un client remoto per testare il server (da una finestra Prompt comandi, in modalita amministratore, lanciare il comando lusrmgr, selezionare la cartella "User").
All'utente creato disabilitargli l'uso del Remote Desktop (sempre dalla finestra lusrmgr, tasto Dx del mouse sull'utente creato andare sul TAB "Remote Desktop Services Profile" e ceccare "Deny this user permissions to log on to Remote Desktop Session Host").
A questi utenti locali alla cartella indicata si aggiungerà un utente locale particolare IIS_IUSERS, necessario se al passo dell'installazione dell'applicazione web su IIS si sceglie di NON installarla nella cartella di default C:\inetpub\wwwroot.

Per una questione di sicurezza sarebbe opportuno disabilitare l'utente dalla possibilità di utilizzare il Remote Desktop.

Utenti di dominio

Questo scenario è più confacente in un ambiente aziendale, pertanto dato un dominio ed un subset di utenti è possibile abilitarli sul server al servizio Git in tal modo essi potranno accedere usando le credenziali aggiornate senza usarne delle nuove.
Segue un esempio di come si imposti l'accesso al repositori mediante l'istruzione CLONE con indicazione dell'utenza in dominio (es. DominioAziendale\IoSonoIo):

> git clone https:\\DominioAziendale\IoSonoIo@serverGit.Azienda.it/Git_IIS/MioRepoTest NomeCartellaLocale

Seguirà l'apertura di un popup con la richiesta di credenziali. A causa di un baco il carattere back slash che separa il nome-dominio dallo user-name verrà riportato nel popup duplicato, va rimosso pena fallimento dell'autenticazione.
Notare che ancor prima della conclusione dell'autenticazione sul client verrà creata la cartella dell'esempio "NomeCartellaLocale", se l'autenticazione fallirà la cartella verrà automaticamente rimossa.

4. Configurazione utente locale al Server

Si assegna all'utente "GitUser1" il permesso full Control alla cartella del repository di Git creata allo Step 2 D:\Git_Repository

5. Impostazione del Git repository

Ci sono due tipologie di repository:

• Repository "non-bare", Standard, destinato ad accoglere un progetto in modo da poterci lavorare direttamente quindi include la Working directory oltre che la cartella nascosta di controllo ".git".
• "Bare Repository", che è destinato ad accogliere un repository centrale e da aggiornare con contributi da vari "client". Una volta creato non ha working directory ma ha solo la cartella di controllo ".git", questo vuol dire che non ci si potrà lavorare direttamente ma il repository serve solo ad accogliere le modifiche dai client.

Vedi qui stackoverflow

Non-bare Repository

E' la situazione di utilizzo collaborativo diretto per cui c'è sia la cartella nascosta di controllo, .git che la working directory ovvero i files e cartelle che si vogliono conservare e gestire. Se il progetto da controllare si chiama "ProgettoTest01", il comando da lanciare mediante "Git CMD" è:

git init ProgettoTest01.git

A questo punto si potranno creare\copiare nella cartella "ProgettoTest01.git" appena creata tutti i files necessari quindi procedere con le operazioni operative per il controllo del codice sorgente o di quant'altro si vuole versionare.

Bare repository

Si inizia con la creazione di uno spazio "vuoto" ovvero predisposto a contenere un progetto e comunque senza la "Working directory", si noterà solo la cartella nascosta di gestione .git. Si potranno vedere solo gli oggetti come li gestisce Git, sono compressi e serializzati in SHA1. Non si può vedere come un progetto è strutturato. (Come usre un bare repository stackoverflow).
Questa scelta assolve in primo luogo a due scopi:

• proteggere il contenuto del repository che sarà compresso e soprattutto criptato (nella cartella .\objects);
• centralizzare il backup ed il contributo dei collaboratori, come se si lavorasse col server di SVN.

Esempio interno: [Es Remote bare repository 1]
Se lo spazio da controllare con Git lo si vuol chiamare "ProgettiTest", il comando da lanciare mediante "Git CMD" è:

git init --bare ProgettiTest.git

Ovviamente il passo successivo è "riempirla" con i progetti da custodire e gestire, questo ottiene con appositi comandi Git, supponiamo da qui in poi che abbiamo già compiuto questi passi.
Nota, per convenzione il nome del progetto, quindi della cartella, deve finire per .git

ATTENZIONE la cartella "ProgettiTest.git" non è detto che abbia come cartella padre la "D:\Git_Repository" perchè dipende dalla scelta che si farà al punto 6, in questo esempio, la cartella padre sarà "Git_IIS" perchè su IIS usiamo una WebApplication e non un WebSite (percorso completo: D:\Git_Repository\Git_IIS\ProgettiTest.git).

6. Creazione Website su IIS

IIS fungerà da intermediario attraverso il quale le richieste operative (Clone, Push, Commit) dai client remoti giungeranno al motore di Git presente sul Server.
Ciascun client sarà rappresentato da una utenza di Sistema Operativo del server che si associerà alla cartella creata al punto 2.
IIS riceverà le richieste perché in ascolto su una porta, la 80 per l'HTTP o la 443 in caso si usi il protocollo HTTPS. Le richieste saranno indirizzate ad una applicazione di Git, git-http-backend.exe questo avverrà grazie ad una configurazione del'"Handler Mapping" associato al sito che creeremo su IIS.

L'intermediazione di IIS la si può ottenere in due modi: creando un nuovo "WebSite" o aggiungendo una nuova "Applicazione Web" a quella di default (LinkInterno). La seconda strada è la più complicata ma è quella che seguiremo in questa guida.
Seguire i passi come nel seguente screenshot:

Prendere nota del nome dell'Application Pool associato alla WebApplication, che se non viene cambiato si chiama "Git_IIS", questa configurazione necessita della seguente modifiche da eseguire andando direttamente sul file di configurazione del Web Server. Aprire con un editor di testo il file:
C:\Windows\System32\inetsrv\Config\applicationHost.config
Cercare la sezione il cui TAG è <applicationPools> e l'elemnto con ID uguale all'Application Pool dell'applicazione creata, "Git_IIS" e modificarlo (fare prima una copia per backup):

...etc
<applicationPools>
        <add name="DefaultAppPool" />
...etc
        <add name="Default Web Site" enable32BitAppOnWin64="false" />
        <add name="Git_IIS" managedRuntimeVersion="">
            <environmentVariables>
                <add name="GIT_PROJECT_ROOT" value="" />
                <add name="GIT_HTTP_EXPORT_ALL" value="1" />
            </environmentVariables>
        </add>
</applicationPools>
...etc

Lo scopo è rendere evidenti due variabili destinate all'ambiente Git ovvero GIT_PROJECT_ROOT e GIT_HTTP_EXPORT_ALL.
Quindi la configurazione dell'Application Pool risulterà così:

7. Server Role

E' necessario che IIS abbia le funzionalità di Basic Authentication (per l'autenticazione degli utenti con credenziali già impostate alla creaziome) e CGI per l'interazione con Git usando il protocollo HTTP.
Queste due funzionalità si installano\verificano sul server usando "Server Manager" se il sistema Operativo è di tipo Server o se è un Windows Professional si andrà al pannello di controllo.
Su un sistema operativo di tipo Server, cercare e lanciare l'applicativo "Server Manager", al centro della finestra selezionare "2 Add roles and features", andare avanti sino ad avere la seguente schermata dove van ceccate due opzioni in particolare:

Su un sistema operativo Windows Professional:
Pannello di controllo

e

8. Configurazione IIS, nuovo Script Map

In IIS Manager aggiungere un nuovo "Script Map", serve a collegare i comandi che giungeranno via HTTP all'applicazione (git-http-backend.exe) di Git che provvederà ad interpretarli ed eseguirli.
Fare doppio click su "Handler Mappings":

Dalla barra laterale sinistra cliccare su "Add Script Map...", si configura come segue, impostando l' "Executable" al seguente eseguibile:
C:\Program Files\Git\mingw64\libexec\git-core\git-http-backend.exe
questo avrà la funzione di collegare le richieste HTTTP a Git.
(in altro tutorial ho letto che invece si può usare "Add Module Mapping..." ed in più rispetto qui si sceglie il modulo "FastCgiModule" ma non l'ho testato)

9. Configurazione IIS, impostazione Basic Authentication

Gli utenti creati al punto 3. si autenticheranno usando la "Basic Authentication" cioè quando faranno ogni operazione verso il server Git dovranno inserire, in realtà, solo la password come illustarto in seguito.
Selezionata l'applicazione Web "Git_IIS" fare doppio click sull'icona "Authentication":

Quindi disabilitare l'autenticazione anonima ed abilitare quella basic:

10. Accesso lato Client, test

A questo punto sarà possibile accedere in remoto a tutti i repository conservati sul server.
Premesso che l'archivio sul server è stato già predisposto ad esser gestito da Git (come al punto 5 con "git init"), il client è ancora sprovvisto di archivio del quale se ne vuole una copia (effettuabile con "git clone"). In base all'esempio in questa guida lanciare Git CMD col seguente comando:

git clone http://GitUser1@git.myserver.com/Git_IIS/ProgettoTest01.git

All'apertura del popup di richiesta password dell'utente GitUser1 digitare quella prevista sul Windows server.

La clonazione creerà una cartella nascosta .git quindi si avrà:

Nota.
La password verrà chiesta solo una volta perché verrà memorizzata sul Server.

11. Configurazione canale HTTPS

ToDo (da completare)...
Dopo un primo test è opportuno configurare l'uso del protocollo HTTPS pertanto il primo step è la richiesta di un certificato e l'installazione, seguire la guida interna [qui].
Il certificato sarà associato al Web site gestito mediante IIS, in questo caso useremo il "Default Web Site" pertanto verrà esteso a tutte le applicazioni Web che gestisce ed in particolare a quella che farà da interfaccia al servizio Git.
Inizialmente il certificato può essere uno di test, "Self-Signed", in attesa di ottenere quello ufficiale quindi aprire IIS Manager:

• selezionare il nodo radice nelle "Connections";
• nel gruppo di icone "IIS" selezioanre "Server Certificates" e farci doppio click.

Quindi creare un certificato di tipo "Web Hosting":

Terminata l'operazione, in questo caso, visto che il certificato è di test non sarà necessario installarlo, si procederà col Binding.

NOTA, se, come nel nostro caso, non si usa specificare un HostName (perché la URL si riferirà al nome di default del HostName server) andrà cancellato il binding su altre porte lasciando solo il riferimento alla 443.

Fonti

"how setup a Windows git remote serve"

• How to run a Git server on Windows with IIS: smalltech.com.au
• How to Install and Configure Git on a Windows Server: opensourceforu.com

Appunti

Dizionario

Link interno: Dizionario

Mappa e Link

---

C# | Source Control | Git operazioni tipiche | Git in Visual Studio

---

IIS | Visual Studio | Visual Studio code | MS SQL | Dizionario

---

Parole chiave: