current git git-workflow

current - git config-- global push default



Git Workflow: sin un servidor (7)

Se supone que git es un sistema descentralizado, pero todos los tutoriales y los flujos de trabajo de mejores prácticas que he encontrado en google sugieren usar un servidor (por lo general, github o configurar uno propio).

Estoy usando git para pequeños proyectos personales (2-3 personas), donde puedo encontrar un flujo de trabajo de mejores prácticas para sincronizar los cambios directamente entre las máquinas de miembros del equipo. Alternativamente, ¿cuáles son algunos argumentos convincentes de por qué debería evitar esto y en su lugar configurar un servidor ''central''?

Gracias,
Ben

Como se ha mencionado, Git funciona realmente bien sin un servidor centralizado. Pero una buena razón para tener un servidor central es tener un lugar "siempre encendido" para enviar el código una vez que se completa una característica que otros desarrolladores pueden obtener sin tener que tener acceso a su máquina local.

Por ejemplo, actualmente trabajo en un equipo de desarrollo de 3 hombres. Todos trabajamos en computadoras portátiles. Podríamos tener un flujo de trabajo en el que simplemente tiremos de las máquinas de los demás. Pero si trabajo en una función y arriesgo mis posibilidades después de que todos hayan salido de la oficina y quiero que miran con este sistema, no pueden hacer nada a menos que mi computadora portátil esté encendida y disponible en la red. Si los muchachos aparecen antes que yo (lo que siempre hacen) tienen que esperar hasta que mi laptop vuelva a estar en línea.

Si busco algo como BitBucket o GitHub o simplemente un servidor siempre en la oficina, cualquiera de los otros desarrolladores puede simplemente hacer los cambios que he hecho cuando estén disponibles en línea.

Para mí, esa es la razón principal para tener un servidor central, y realmente no es una falla con Git sino más bien una consecuencia de trabajar con computadoras portátiles.

Debe configurar un servidor central como una construcción social, no técnica, para que todos sepan dónde encontrar la última versión oficial, sin ninguna posibilidad de confusión.

Depende de lo que quiere decir con "servidor". Git funcionará felizmente sin un servidor central, aunque muchos equipos consideran conveniente tener un repositorio central.

Si por "servidor", quiere decir "instalar software de servidor", git también funcionará (repositorio central o no) sin ningún software especial, a través de ssh o en el sistema de archivos.

Ver este documento para posibles flujos de trabajo

Flujo de trabajo con repositorio común

El flujo de trabajo que muchos utilizan es que todos los desarrolladores "envían" (envían) sus cambios a un repositorio común y obtienen todos los cambios de ese repositorio. Algo como esto:

  • Desarrollador A empuja a central
  • Desarrollador B empuja a central
  • El desarrollador C tira (obteniendo cambios de A y B)
  • El desarrollador A tira (obteniendo cambios de B)
  • ...

En este caso, el repositorio central puede estar en una de las computadoras de Desarrolladores, en Github o en cualquier otro lugar

Flujo de trabajo con correo electrónico

También puede usar git sin ningún servidor, simplemente usando el correo electrónico. En este caso, el flujo sería así:

  • El desarrollador A envía cambios como un correo electrónico al equipo
  • Otros desarrolladores aplican los cambios de los correos electrónicos

Esto incluso se puede hacer de una manera semiautomatizada

Flujo de trabajo sin un servidor central

Puede configurar git para usar más de un repositorio "remoto". La advertencia es que nunca debe presionar a un repositorio que está prestado (es decir, una copia del Desarrollador en la que alguien está trabajando). Entonces, en este caso, el flujo sería así:

  • Desarrollador A hace cambios
  • Desarrollador B hace cambios
  • Desarrollador C extrae cambios de A
  • Desarrollador C extrae cambios de B
  • Desarrollador B extrae cambios de A
  • ...
  • Nadie debe empujar

En mi humilde opinión, este tipo de flujo de trabajo conducirá rápidamente a confusión y desglose.

Git funciona bastante bien con este tipo de configuración, aunque querrás evitar forzar cambios en la sucursal de otra persona ( https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F ). Es posible que tenga una bifurcación de integración a la que aplique el código y combine los cambios de otras personas.

Creo que la razón principal por la que se utiliza mucho un repositorio central es que puede tomarse como la base canónica de todo el código, mientras que puede ser un poco más difícil razonar sobre qué se debe fusionar cuando tiene 3 o más ramas de desarrollo pasando.

Lo primero que debe hacer es pensar qué tipo de flujo de trabajo ya tiene y configurarlo para que funcione. Una vez que tiene algo en funcionamiento, puede ajustarlo. No es necesario configurar una computadora separada como servidor. Si está acostumbrado a tener un repositorio central, todo lo que necesita hacer es crear un repositorio vacío al que todos le presten ayuda. ¿Por qué no en la red local?

Repo central:

mkdir foo.git cd foo.git git init --bare

Tu repositorio:

mkdir foo cd foo git init // add files git add . git commit -m "Initial commit" git remote add origin //path/to/central/repo/foo.git git push origin master

Otros repositorios:

git clone //path/to/central/repo/foo.git

Ahora cualquiera puede empujar y tirar directamente desde la rama principal. Esto debería ser suficiente para comenzar.

No es necesario que coloque una copia en un servidor físico en alguna parte, pero puede ser útil contar con un repositorio "bendecido" en alguna parte: haga que uno de su equipo (posiblemente en rotación) sea responsable de recopilar y gestionar los cambios de las personas cuando están listos para ser tratados como definitivos. Pueden mantener una sucursal en su repositorio habitual o mantener un repositorio separado en su sistema local para almacenar las fuentes maestras.

Como ejemplo concreto, considere Linux y Linus Torvalds: no hay un repositorio central al que todo el mundo preste atención, pero Linus mantiene un repositorio que contiene todo el código que considera "listo" (y lo mismo hacen otras personas, para diferentes definiciones de '' Listo''). De esta forma, tendrá una definición canónica de qué código se encuentra y un lugar para definir cuáles son sus lanzamientos.