Si desea configurar el control de código fuente para un proyecto, pero prefiere no alojarlo en un servicio como GitHub, puede ejecutar el suyo git servidor en un VPS para guardar su código y actuar como un repositorio maestro para cualquier colaborador.
¿Por qué ejecutar su propio servidor?
Con cuántos hospedados gratis git proveedores que hay, como GitHub, GitLab, y Bitbucket, no tiene mucho sentido hacerlo usted mismo. Pero hay algunas situaciones en las que es una solución viable.
En primer lugar, ejecutar su propio servidor es mucho más privado, especialmente si está trabajando en un código que prefiere no almacenar en la «nube» de otra persona. Esto no quiere decir que proveedores como GitLab no sean seguros, pero alojar todo usted mismo puede dar a algunas personas más tranquilidad.
Al mismo tiempo, si está usando un servicio de terceros, existen restricciones en el tamaño del archivo que pueden no ser ideales. GitHub no posibilita archivos de más de 100 MB, lo que puede ser un obstáculo importante para proyectos con archivos binarios grandes. El uso de su propio servidor elimina este límite, suponiendo que pueda pagar por más espacio en el disco duro.
Cualquiera que sea su caso de uso, probablemente pueda hacerlo mejor que barebones git. De GitLab Edición de la comunidad es sin costes y open source, y es fácil de configurar en su propio servidor. Esto le brinda todos los beneficios de alojarlo usted mismo junto con una interfaz web muy agradable y numerosas herramientas de CI / CD. Le sugerimos encarecidamente que utilice GitLab si tiene espacio libre en el servidor. (Necesita alrededor de 3 GB de RAM). Puede leer nuestra guía para instalarlo y configurarlo para obtener más información.
Pero, si no quiere todas las campanas y silbidos, y solo quiere ejecutar un simple git remoto, puedes seguir leyendo.
Los controles remotos de Git son solo el repositorio de otra persona
Lo primero a prestar atención git es que alojar un servidor no es verdaderamente muy complicado. Git utiliza un modelo de control de código fuente distribuido; su clon local de un repositorio no se conecta a todos sus compañeros de trabajo en absoluto, pero sí se conecta a un «remoto», de forma general en un servidor o servicio central externo. Cuando empuja y tira, realiza modificaciones en la copia maestra oficial del control remoto. Cuando sus compañeros de trabajo buscan desde el control remoto, descargan sus confirmaciones.
Técnicamente puedes ejecutar git como un servicio absolutamente descentralizado. Si tuvieras dos personas, cada una obtendría actualizaciones de la otra. (No se recomienda enviar a repositorios que no sean de servidor en esta configuración). Esto no es verdaderamente utilizable en la práctica, a menos que ambas partes tengan direcciones IP estáticas y estén siempre en línea, por lo que la mayoría de la gente opta por el modelo servidor-cliente.
Entonces, todo eso git El servidor es entonces solo un repositorio regular que está configurado como la copia maestra y está abierto a Internet. Es sorprendentemente sencillo de configurar. Primero, necesitaremos crear un nuevo usuario. Git utiliza SSH para la autenticación y todo el tráfico entre servidores y clientes, por lo que necesitaremos un usuario de servicio para administrar el repositorio.
sudo useradd git
A continuación, cambie al git usuario para el resto de la configuración:
su git
Deberá agregar sus claves SSH al git usuario authorized_keys expediente:
nano ~/.ssh/authorized_keys
Esta es un área donde servicios como GitHub y GitLab disponen línea de comando Git beat. La administración de acceso no se maneja fácilmente de esta manera, dado que deberá darles a todos acceso al mismo usuario del servicio, lo cual no es ideal, o deberá configurar usuarios separados para cada persona, lo cual tampoco lo es. ideal. De cualquier manera, las confirmaciones aparecerán con cualquier nombre de usuario y email que el usuario final haya configurado en su git ajustes.
De todos modos, para crear el repositorio real, simplemente ejecute git init en el git directorio de inicio del usuario:
git init --bare repository.git
los --bare La opción es necesaria aquí. Por lo general, cuando clona un repositorio, git almacena todos los archivos que utiliza para administrar versiones en el oculto .git carpeta, y mantiene una versión utilizable de donde sea que se encuentre su HEAD en este momento desprotegido. Esto de forma general hace que su carpeta de repositorio sea aproximadamente el doble de grande de lo que sería sin git, aún cuando puede ser más grande si tiene archivos binarios grandes y muchos cambios a lo largo del tiempo.
Un repositorio simple es simplemente un repositorio sin las versiones utilizables de los archivos en este momento extraídos. En cambio, la carpeta del repositorio es solo el contenido de lo que sería el .git carpeta. Esto ahorra espacio de almacenamiento y configura el repositorio como servidor maestro. Debido a que no hay contenido local, no habrá conflictos con la rama HEAD. Es una convención nombrar repositorios desnudos con el .git extensión de archivo, pero no se necesita explícitamente.
Eso es todo lo que se necesita en el lado del servidor. Desde su máquina local, deberá clonar el repositorio o agregar un nuevo control remoto:
git remote add origin [email protected]:repository.git
La URL comienza con git@ debido a que se conecta a través de SSH como el git usuario. los :repository.git al final es en realidad un nombre de ruta, no solo un identificador. El camino es relativo al git directorio de inicio del usuario, por lo que si colocó el repositorio en otro lugar, querrá moverlo aquí o utilizar la ruta completa.
Una vez que haya conectado su repositorio local, debería tener acceso completo para empujar y tirar como de costumbre. Tenga en cuenta, a pesar de esto, que el valor predeterminado git no tiene un sistema de permisos incorporado, por lo que no hay nada que impida a cualquier persona con acceso al git que el usuario tenga control total sobre su repositorio principal.
