Come creare un repository Git remoto da uno locale?

Ho un repository Git locale. Vorrei renderlo disponibile su un server remoto abilitato per ssh. Come faccio a fare questo?

Penso che tu crei un repository nudo sul lato remoto git init --bare, aggiungi il lato remoto come tracker push / pull per il tuo repository locale ( git remote add origin URL), e poi localmente dici git push origin master. Ora qualsiasi altro repository può pulldal repository remoto.

Per configurare inizialmente qualsiasi server Git, devi esportare un repository esistente in un nuovo repository nudo, un repository che non contiene una directory di lavoro. Questo è generalmente semplice da fare. Per clonare il repository per creare un nuovo repository nudo, si esegue il comando clone con l' --bareopzione. Per convenzione, finiscono le directory dei repository nudi .git, in questo modo:

$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/

Questo comando prende il repository Git da solo, senza una directory di lavoro, e crea una directory appositamente per esso da solo.

Ora che hai una copia nuda del tuo repository, tutto ciò che devi fare è metterlo su un server e impostare i tuoi protocolli. Supponiamo che tu abbia configurato un server chiamato a git.example.comcui hai accesso SSH e desideri archiviare tutti i tuoi repository Git nella /opt/gitdirectory. È possibile impostare il nuovo repository copiando il repository nudo su:

$ scp -r my_project.git user@git.example.com:/opt/git

A questo punto, altri utenti che hanno accesso SSH allo stesso server che ha accesso in lettura alla /opt/gitdirectory possono clonare il repository eseguendo

$ git clone user@git.example.com:/opt/git/my_project.git

Se un utente SSH in un server e ha accesso in scrittura alla /opt/git/my_project.gitdirectory, avrà anche automaticamente l'accesso push. Git aggiungerà automaticamente le autorizzazioni di scrittura di gruppo a un repository correttamente se si esegue il comando git init con l' --sharedopzione.

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared

È molto facile prendere un repository Git, creare una versione non elaborata e posizionarlo su un server a cui tu e i tuoi collaboratori avete accesso a SSH. Ora sei pronto per collaborare allo stesso progetto.

Una nota per le persone che hanno creato la copia locale su Windows e desiderano creare un repository remoto corrispondente su un sistema di linea Unix, in cui i file di testo ottengono terminazioni LF su ulteriori cloni da parte di sviluppatori su sistemi simili a Unix, ma terminazioni CRLF su Windows.

Se hai creato il tuo repository di Windows prima di impostare la traduzione di fine riga, allora hai un problema. L'impostazione predefinita di Git non è una traduzione, quindi il tuo working set utilizza CRLF ma il tuo repository (ovvero i dati memorizzati in .git) ha salvato anche i file come CRLF.

Quando si preme sul telecomando, i file salvati vengono copiati così come sono, non si verifica alcuna traduzione di fine riga. (La traduzione di fine riga si verifica quando i file vengono sottoposti a commit in un repository, non quando viene inviato il repository). Finisci con CRLF nel tuo repository simile a Unix, che non è quello che vuoi.

Per ottenere LF nel repository remoto devi prima assicurarti che LF sia nel repository locale, normalizzando nuovamente il tuo repository Windows . Ciò non avrà alcun effetto visibile sul set di lavoro di Windows, che ha ancora terminazioni CRLF, tuttavia quando si passa al telecomando, il telecomando otterrà LF correttamente.

Non sono sicuro se c'è un modo semplice per dire quali finali di linea hai nel tuo repository di Windows - Immagino che potresti testarlo impostando core.autocrlf = false e quindi clonando (Se il repository ha terminazioni LF, il clone avrà Anche LF).

C'è una differenza interessante tra le due soluzioni popolari sopra:

1. Se si crea il repository nudo in questo modo:

   cd / outside_of_any_repo
   mkdir my_remote.git
   cd my_remote.git
   git init --bare
   

e poi

cd  /your_path/original_repo
git remote add origin /outside_of_any_repo/my_remote.git
git push --set-upstream origin master

Quindi git imposta la configurazione in 'original_repo' con questa relazione:

original_repo origin --> /outside_of_any_repo/my_remote.git/

con quest'ultimo come telecomando a monte. E il telecomando upstream non ha altri telecomandi nella sua configurazione.

2. Tuttavia, se lo fai al contrario:

   (dalla directory original_repo)
   cd ..
   git clone --bare original_repo /outside_of_any_repo/my_remote.git
   

quindi 'my_remote.git' si conclude con la sua configurazione con 'origin' che punta a 'original_repo' come un telecomando, con un remote.origin.url uguale al percorso della directory locale, che potrebbe non essere appropriato se verrà spostato a un server.

Mentre quel riferimento "remoto" è facile da eliminare in seguito se non è appropriato, 'original_repo' deve ancora essere impostato per puntare a 'my_remote.git' come un telecomando up-stream (o ovunque vada da condividere). Quindi tecnicamente, puoi ottenere lo stesso risultato con qualche altro passaggio con l'approccio n. 2. Ma il n. 1 sembra un approccio più diretto alla creazione di un "repository condiviso nudo centrale" proveniente da uno locale, appropriato per passare a un server, con meno passaggi. Penso che dipenda dal ruolo che si desidera venga svolto dal repository remoto. (E sì, questo è in conflitto con la documentazione qui .)

Avvertenza: ho appreso quanto sopra (in questo scritto all'inizio di agosto 2019) facendo un test sul mio sistema locale con un repository reale e quindi facendo un confronto file per file tra i risultati. Ma! Sto ancora imparando, quindi potrebbe esserci un modo più corretto. Ma i miei test mi hanno aiutato a concludere che il numero 1 è il mio metodo attualmente preferito.

Un repository remoto è generalmente un repository nudo, un repository Git che non ha directory di lavoro. Poiché il repository viene utilizzato solo come punto di collaborazione, non vi è motivo di estrarre un'istantanea sul disco; sono solo i dati di Git. In parole povere, un repository nudo è il contenuto della directory .git del progetto e nient'altro.

Puoi creare un repository bare git con il seguente codice:

$ git clone --bare /path/to/project project.git

Una delle opzioni per avere un repository git remoto è usare il protocollo SSH:

Un protocollo di trasporto comune per Git quando l'hosting automatico è su SSH. Questo perché l'accesso SSH ai server è già impostato nella maggior parte dei luoghi e, in caso contrario, è facile da fare. SSH è anche un protocollo di rete autenticato e, poiché è onnipresente, è generalmente facile da configurare e utilizzare.

Per clonare un repository Git su SSH, puoi specificare un ssh://URL come questo:

$ git clone ssh://[user@]server/project.git

Oppure puoi usare la sintassi più breve simile a scp per il protocollo SSH:

$ git clone [user@]server:project.git

In entrambi i casi precedenti, se non si specifica il nome utente facoltativo, Git presuppone l'utente come attualmente connesso.

I pro

I pro dell'uso di SSH sono molti. Innanzitutto, SSH è relativamente facile da configurare: i demoni SSH sono all'ordine del giorno, molti amministratori di rete ne hanno esperienza e molte distribuzioni del sistema operativo sono configurate con essi o dispongono di strumenti per gestirli. Successivamente, l'accesso tramite SSH è sicuro: tutti i trasferimenti di dati sono crittografati e autenticati. Infine, come i protocolli HTTPS, Git e Local, SSH è efficiente, rendendo i dati il ​​più compatti possibile prima di trasferirli.

I contro

L'aspetto negativo di SSH è che non supporta l'accesso anonimo al tuo repository Git. Se stai usando SSH, le persone devono avere accesso SSH alla tua macchina, anche in sola lettura, il che non rende SSH favorevole ai progetti open source per i quali le persone potrebbero semplicemente voler clonare il tuo repository per esaminarlo. Se lo stai utilizzando solo all'interno della tua rete aziendale, SSH potrebbe essere l'unico protocollo che devi affrontare. Se si desidera consentire l'accesso anonimo in sola lettura ai propri progetti e si desidera utilizzare SSH, è necessario impostare SSH in modo che si possa eseguire il push ma qualcos'altro da cui gli altri possano recuperare.

Per ulteriori informazioni, consultare il riferimento: Git sul server - I protocolli

Devi creare una directory su un server remoto. Quindi utilizzare il comando "git init" per impostarlo come repository. Questo dovrebbe essere fatto per ogni nuovo progetto che hai (ogni nuova cartella)

Supponendo che abbiate già configurato e usato git usando i tasti ssh, ho scritto un piccolo script Python, che quando eseguito da una directory di lavoro imposterà un telecomando e inizializzerà la directory come repository git. Ovviamente, dovrai modificare lo script (solo una volta) per dire al server e al percorso principale per tutti i repository.

Controlla qui - https://github.com/skbobade/ocgi

Normalmente puoi impostare un repository git semplicemente usando il initcomando

git init

Nel tuo caso, è già disponibile un repository su un telecomando. A seconda di come accedi al tuo repository remoto (con nome utente all'interno dell'url o un tasto ssh che gestisce la verifica) usa solo il clonecomando:

git clone git@[my.url.com]:[git-repo-name].git

Esistono anche altri modi per clonare il repository. In questo modo lo chiami se sul tuo computer è installato un tasto ssh che verifica il pull del tuo repository. Esistono altre combinazioni dell'URL se si desidera includere la password e il nome utente all'interno per accedere al repository remoto.