Respuestas:
Creo que crea un repositorio desnudo en el lado remoto git init --bare, agrega el lado remoto como el rastreador push / pull para su repositorio local ( git remote add origin URL) y luego localmente solo dice git push origin master. Ahora cualquier otro repositorio puede pulldesde el repositorio remoto.
git push origin masterfalla con el error "no se encontró el repositorio", intente git update-server-infoen el lado remoto, donde lo hizogit init --bare
git update-server-infopero recibo el error fatal: Unable to look up Volumes (port 9418) (nodename nor servname provided, or not known)
Para configurar inicialmente cualquier servidor Git, debe exportar un repositorio existente a un nuevo repositorio desnudo, un repositorio que no contiene un directorio de trabajo. Esto es generalmente sencillo de hacer. Para clonar su repositorio para crear un nuevo repositorio desnudo, ejecute el comando clonar con la --bareopción. Por convención, los directorios de repositorio desnudos terminan .gitasí:
$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/
Este comando toma el repositorio Git por sí mismo, sin un directorio de trabajo, y crea un directorio específicamente para él solo.
Ahora que tiene una copia desnuda de su repositorio, todo lo que necesita hacer es ponerlo en un servidor y configurar sus protocolos. Digamos que ha configurado un servidor llamado al git.example.comque tiene acceso SSH y desea almacenar todos sus repositorios Git en el /opt/gitdirectorio. Puede configurar su nuevo repositorio copiando su repositorio desnudo sobre:
$ scp -r my_project.git user@git.example.com:/opt/git
En este punto, otros usuarios que tienen acceso SSH al mismo servidor que tiene acceso de lectura al /opt/gitdirectorio pueden clonar su repositorio ejecutando
$ git clone user@git.example.com:/opt/git/my_project.git
Si un usuario SSH ingresa a un servidor y tiene acceso de escritura al /opt/git/my_project.gitdirectorio, también tendrá automáticamente acceso push. Git agregará automáticamente permisos de escritura grupal a un repositorio correctamente si ejecuta el comando git init con la --sharedopción.
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared
Es muy fácil tomar un repositorio Git, crear una versión básica y colocarlo en un servidor al que usted y sus colaboradores tengan acceso SSH. Ahora estás listo para colaborar en el mismo proyecto.
scpsolución funciona IMO mejor en la práctica que el init --bare. Sin embargo, todavía se siente como un truco feo clonar primero localmente, luego copiar al servidor ... desearía que git tuviera un comando para hacerlo de una vez.
--sharedfuncionó para mí. Me pregunto qué pasará si lo usas git init --sharedsin hacer --bareuno ...
scpeso para un control remoto funciona mejor si el control remoto no es compatible git init --bare(como fue el caso con git 1.5.5, 2008). Creo que esto debería funcionar incluso si el control remoto no tiene git.
Una nota para las personas que crearon la copia local en Windows y desean crear un repositorio remoto correspondiente en un sistema de línea Unix, donde los archivos de texto obtienen terminaciones LF en clones adicionales por parte de desarrolladores en sistemas similares a Unix, pero terminaciones CRLF en Windows.
Si creó su repositorio de Windows antes de configurar la traducción de final de línea, entonces tiene un problema. La configuración predeterminada de Git no es traducción, por lo que su conjunto de trabajo usa CRLF pero su repositorio (es decir, los datos almacenados en .git) también ha guardado los archivos como CRLF.
Cuando presiona el control remoto, los archivos guardados se copian tal cual, no se produce la traducción de final de línea. (La traducción de finalización de línea ocurre cuando los archivos se envían a un repositorio, no cuando se envían repositorios). Terminas con CRLF en tu repositorio tipo Unix, que no es lo que quieres.
Para obtener LF en el repositorio remoto, primero debe asegurarse de que LF esté en el repositorio local, normalizando nuevamente su repositorio de Windows . Esto no tendrá ningún efecto visible en su conjunto de trabajo de Windows, que todavía tiene terminaciones CRLF, sin embargo, cuando presiona el control remoto, el control remoto obtendrá LF correctamente.
No estoy seguro de si hay una manera fácil de saber qué terminaciones de línea tiene en su repositorio de Windows. Supongo que puede probarlo configurando core.autocrlf = false y luego clonando (si el repositorio tiene terminaciones LF, el clon tendrá LF también).
Hay una diferencia interesante entre las dos soluciones populares anteriores:
Si crea el repositorio simple de esta manera:
cd / outside_of_any_repo mkdir my_remote.git cd my_remote.git git init --bare
y entonces
cd /your_path/original_repo
git remote add origin /outside_of_any_repo/my_remote.git
git push --set-upstream origin master
Luego, git configura la configuración en 'original_repo' con esta relación:
original_repo origin --> /outside_of_any_repo/my_remote.git/
con este último como el control remoto aguas arriba. Y el control remoto ascendente no tiene ningún otro control remoto en su configuración.
Sin embargo, si lo haces al revés:
(del directorio original_repo) discos compactos .. git clone --bare original_repo /outside_of_any_repo/my_remote.git
entonces 'my_remote.git' termina con su configuración que tiene 'origen' apuntando a 'original_repo' como remoto, con un remote.origin.url que equivale a la ruta del directorio local, lo que podría no ser apropiado si se va a mover a un servidor
Si bien esa referencia "remota" es fácil de eliminar más adelante si no es apropiada, 'original_repo' todavía debe configurarse para que apunte a 'my_remote.git' como un control remoto ascendente (o hacia donde vaya) para ser compartido desde). Entonces, técnicamente, puede llegar al mismo resultado con unos pocos pasos más con el enfoque n. ° 2. Pero el n. ° 1 parece un enfoque más directo para crear un "repositorio compartido desnudo central" que se origina en uno local, apropiado para pasar a un servidor, con menos pasos involucrados. Creo que depende del papel que desee que desempeñe el repositorio remoto. (Y sí, esto está en conflicto con la documentación aquí ).
Advertencia: aprendí lo anterior (en este escrito a principios de agosto de 2019) haciendo una prueba en mi sistema local con un repositorio real, y luego haciendo una comparación de archivo por archivo entre los resultados. ¡Pero! Todavía estoy aprendiendo, por lo que podría haber una forma más correcta. Pero mis pruebas me han ayudado a concluir que el # 1 es mi método preferido actualmente.
Un repositorio remoto es generalmente un repositorio simple, un repositorio Git que no tiene un directorio de trabajo. Debido a que el repositorio solo se usa como un punto de colaboración, no hay razón para tener una instantánea desprotegida en el disco; son solo los datos de Git. En los términos más simples, un repositorio simple es el contenido del directorio .git de su proyecto y nada más.
Puede hacer un repositorio de git desnudo con el siguiente código:
$ git clone --bare /path/to/project project.git
Una opción para tener un repositorio git remoto es usar el protocolo SSH:
Un protocolo de transporte común para Git cuando el autohospedaje es a través de SSH. Esto se debe a que el acceso SSH a los servidores ya está configurado en la mayoría de los lugares, y si no es así, es fácil de hacer. SSH también es un protocolo de red autenticado y, como es omnipresente, generalmente es fácil de configurar y usar.
Para clonar un repositorio de Git sobre SSH, puede especificar una
ssh://URL como esta:$ git clone ssh://[user@]server/project.gitO puede usar la sintaxis más corta tipo scp para el protocolo SSH:
$ git clone [user@]server:project.gitEn los dos casos anteriores, si no especifica el nombre de usuario opcional, Git asume el usuario con el que está conectado actualmente.
Los profesionales
Las ventajas de usar SSH son muchas. Primero, SSH es relativamente fácil de configurar: los demonios SSH son comunes, muchos administradores de red tienen experiencia con ellos y muchas distribuciones de SO se configuran con ellos o tienen herramientas para administrarlos. A continuación, el acceso a través de SSH es seguro: toda la transferencia de datos se cifra y se autentica. Por último, al igual que los protocolos HTTPS, Git y Local, SSH es eficiente, lo que hace que los datos sean lo más compactos posible antes de transferirlos.
Los contras
El aspecto negativo de SSH es que no admite acceso anónimo a su repositorio Git. Si está utilizando SSH, las personas deben tener acceso SSH a su máquina, incluso en una capacidad de solo lectura, lo que no hace que SSH sea propicio para proyectos de código abierto para los que las personas simplemente quieran clonar su repositorio para examinarlo. Si lo está utilizando solo dentro de su red corporativa, SSH puede ser el único protocolo con el que debe lidiar. Si desea permitir el acceso anónimo de solo lectura a sus proyectos y también desea usar SSH, tendrá que configurar SSH para que pueda avanzar, pero hay algo más para que otros obtengan.
Para obtener más información, consulte la referencia: Git en el servidor - Los protocolos
Necesita crear un directorio en un servidor remoto. Luego use el comando "git init" para configurarlo como un repositorio. Esto debe hacerse para cada nuevo proyecto que tenga (cada nueva carpeta)
Suponiendo que ya ha configurado y usado git usando las teclas ssh, escribí un pequeño script de Python, que cuando se ejecuta desde un directorio de trabajo configurará un control remoto e inicializará el directorio como un repositorio de git. Por supuesto, tendrá que editar el script (solo una vez) para indicarle el servidor y la ruta raíz para todos los repositorios.
Marque aquí: https://github.com/skbobade/ocgi
Normalmente, puedes configurar un repositorio de git simplemente usando el initcomando
git init
En su caso, ya hay un repositorio en un control remoto disponible. Dependiendo de cómo acceda a su repositorio remoto (con nombre de usuario dentro de la url o una clave ssh que maneja la verificación) use solo el clonecomando:
git clone git@[my.url.com]:[git-repo-name].git
También hay otras formas de clonar el repositorio. De esta manera, lo llamará si tiene una configuración de clave ssh en su máquina que verifica al extraer su repositorio. Existen otras combinaciones de la URL si desea incluir su contraseña y nombre de usuario para iniciar sesión en su repositorio remoto.