origin - Manera "adecuada" de llevar git "rama de producción" al servidor de producción

git remote add origin

Question

Soy bastante nuevo en Git, y he leído el libro Pro Git @ http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging . Mi pregunta es si lo que estoy haciendo hoy es la forma preferida de trabajar con el servidor de producción y un repositorio de Git remoto.

Tengo mi repo alojado en GitHub, usando tres sucursales remotas: desarrollo -> pruebas -> maestro.

Cada vez que se verifica que la rama de "prueba" está funcionando, git merge "master" con "testing" (¿avance rápido?) Localmente, y git push "master" a GitHub.

En el servidor de producción (/opt/www/url.com/) he hecho:

git init
git remote add origin https://github.com/.....
git pull origin master

Ahora cada vez que quiero actualizar el master git pull un git pull

git pull origin master

La producción nunca empujará ningún cambio a remoto. Y los cambios locales no sucederán. ¿Lo estoy haciendo bien? Si no es así, ¿cuál es la forma preferida de llevar las actualizaciones a la producción?

Edición n. ° 1: no quiero gestionar ningún conflicto en el servidor de producción, al cual me estoy enfrentando ahora (de alguna manera he hecho algo mal). Simplemente quiero desplegar la última rama maestra actualizada y cambiarla.

Answer 1

Deberías usar:

git init --bare

Para inicializar un repositorio que no tendrá un árbol de trabajo, lo que significa que no habrá conflictos.

Answer 2

Hacer ''git pull'' es bastante común para esto, pero hay una manera más a prueba de balas.

No habría ningún conflicto, si de alguna manera no hicieras cambios locales. Pero si solo desea obtener un árbol actualizado y eliminar cualquier cambio local, hay una mejor manera, que ignora cualquier cosa local:

Primero, necesitas obtener lo último del servidor. En lugar de ''git pull'', para esto, usaremos:

git fetch origin master

Esto hace la primera mitad de un ''git pull''. (El segundo es la fusión en su maestro local, que es donde se encontró con problemas).

Git fetch hace:

1. Encuentra lo que el master master señala en el control remoto.
2. Descargas que se comprometen y todo lo que hace referencia que no tiene localmente.
3. Actualiza la referencia de origen / maestro para que apunte a ese compromiso, para recordar dónde está el control remoto en su versión de "maestro".

A continuación, simplemente actualizaremos nuestro ''maestro'' local para indicar el mismo compromiso y actualizar nuestro árbol de trabajo.

Para esto, utilizaremos:

git reset --hard origin/master

(Suponiendo que no usó un nombre diferente para su repositorio remoto, en lugar del "origen" predeterminado, ajústelo si lo hizo).

Esto en realidad hace tres cosas:

1. Actualiza la rama maestra local para que apunte a la misma confirmación que acaba de obtener del control remoto.
2. Carga ese árbol en tu índice.
3. Actualiza tu árbol de trabajo para que coincida con el índice.

Ahora tiene una rama maestra local y un árbol que coinciden con el control remoto.

Pero hay un paso más, que es limpiar todo lo que queda, que no está siendo seguido por git.

git clean -fdx

Eliminará todos los archivos creados por compilaciones anteriores y le proporcionará un entorno limpio. Debería copiar todos los artefactos de compilación que desee conservar en algún otro lugar en cualquier caso.

''git pull'' está dirigido a los desarrolladores que coordinan su trabajo, por lo que realmente no es la herramienta ideal para este trabajo. ''git fetch'' y ''git reset - hard'' son más específicos, sin las protecciones contra la sobrescritura accidental del trabajo local.

Pero eso es exactamente lo que quieres aquí.

Sin embargo, si a veces realiza cambios para solucionar problemas en el servidor de producción, es posible que desee seguir utilizando ''git pull''. Las fusiones y los posibles conflictos pueden ser más útiles que perjudiciales.

Pero a veces solo desea una actualización confiable como parte de su automatización, y cualquier cambio local es un problema que debe eliminarse.

Pero es probable que desee que ''git clean'' incluso con ''git pull''. Los archivos sobrantes pueden arruinar construcciones e implementaciones de maneras misteriosas y difíciles de identificar.