Si desea configurar el control de código fuente para un proyecto, pero prefiere no alojarlo en un servicio como GitHub, puede ejecutar su propio servidor git en un VPS para almacenar su código y actuar como un repositorio maestro para cualquier colaborador.
¿Por qué ejecutar su propio servidor?
con cuantos gratis proveedores de git alojados haycomo GitHub, GitLaby 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 código que preferiría 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 brindar a algunas personas más tranquilidad.
Además, si utiliza un servicio de terceros, existen restricciones en el tamaño del archivo que pueden no ser las ideales. GitHub no permite archivos superiores a 100 MB, lo que puede ser un problema 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 git básico. de GitLab Edición comunitaria Es gratuito, de código abierto y 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 CI/CD. Le recomendamos encarecidamente que utilice GitLab si tiene espacio libre en el servidor. (Requiere alrededor 3 GB de RAM.) Puede leer nuestra guía para instalarlo y configurarlo para obtener más información.
Pero, si no quieres todas las comodidades y solo quieres ejecutar un control remoto git simple, puedes continuar leyendo.
Los controles remotos de Git son solo el repositorio de otra persona
Lo primero que hay que tener en cuenta sobre git es que alojar un servidor no es realmente muy complicado. Git utiliza un modelo de control de fuente distribuida; su clon local de un repositorio no se conecta a todos sus compañeros de trabajo, pero sí a un “remoto”, generalmente en un servidor o servicio central externo. Cuando empujas y tiras, realizas modificaciones en la copia maestra oficial del control remoto. Cuando sus compañeros de trabajo obtienen datos desde el control remoto, descargan sus confirmaciones.
Técnicamente puedes ejecutar git como un servicio completamente descentralizado. Si tuvieras dos personas, cada una obtendría actualizaciones entre sí. (En esta configuración no se recomienda enviar a repositorios que no sean servidores). Esto no es realmente 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 las personas optan por el modelo servidor-cliente.
Entonces, todo lo que es un servidor git es solo un repositorio normal que está configurado como copia maestra y abierto a Internet. Es sorprendentemente sencillo de configurar. Primero, necesitaremos crear un nuevo usuario. Git usa SSH para la autenticación y todo el tráfico entre servidores y clientes, por lo que necesitaremos un usuario del servicio para administrar el repositorio.
sudo useradd git
A continuación, cambie al usuario git para el resto de la configuración:
su git
Deberá agregar sus claves SSH al archivo autorizado_keys del usuario de git:
nano ~/.ssh/authorized_keys
Esta es un área donde servicios como GitHub y GitLab superan a Git en la línea de comandos. La administración de acceso no se maneja fácilmente de esta manera, ya que deberá darles a todos acceso al mismo usuario del servicio, lo cual no es ideal, o necesitará configurar usuarios separados para cada persona, lo cual tampoco es ideal. ideal. De cualquier manera, las confirmaciones aparecerán con cualquier nombre de usuario y correo electrónico que el usuario final haya configurado en su configuración de git.
De todos modos, para crear el repositorio real, simplemente ejecute git init en el directorio de inicio del usuario de git:
git init --bare repository.git
La opción –bare es necesaria aquí. Por lo general, cuando estás clonando un repositorio, git almacena todos los archivos que usa para administrar las versiones en la carpeta oculta .git, y mantiene una versión utilizable de dondequiera que esté tu HEAD actualmente desprotegido. Esto generalmente hace que su carpeta de repositorio sea aproximadamente el doble de grande de lo que sería sin git, aunque puede ser más grande si tiene archivos binarios grandes y muchos cambios a lo largo del tiempo.
Un repositorio básico es simplemente un repositorio sin las versiones utilizables de los archivos actualmente desprotegidos. En cambio, la carpeta del repositorio es solo el contenido de lo que sería la carpeta .git. Esto ahorra espacio de almacenamiento y configura el repositorio como servidor maestro. Como no hay contenido local, no habrá conflictos con la sucursal HEAD. Es una convención nombrar repositorios básicos con la extensión de archivo .git, pero no es un requisito explícito.
Eso es todo lo que se requiere del 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@ porque se conecta a través de SSH como usuario de git. El :repository.git al final es en realidad un nombre de ruta, no solo un identificador. La ruta es relativa al directorio de inicio del usuario de git, por lo que si colocó el repositorio en otro lugar, querrá moverlo aquí o usar la ruta completa.
Una vez que haya conectado su repositorio local, debería tener acceso completo para empujar y tirar como de costumbre. Sin embargo, tenga en cuenta que git predeterminado no tiene un sistema de permisos integrado, por lo que no hay nada que impida que cualquier persona con acceso al usuario de git tenga control total sobre su repositorio maestro.
