Tire para otra rama de Git sin cambiar

55

Recientemente cambiamos de SVN a Git y al mismo tiempo pusimos nuestros sistemas en vivo en control de versiones (en lugar de pago local y copia de archivos en vivo).

En el proyecto al que estoy asignado, todos accedemos al mismo repositorio y para obtener cambios en vivo, solo estamos git pullallí. Esto causa problemas porque nuestros diseñadores web introducen cambios en el VCS que aún no deberían estar activos pero deberían estar en el entorno de prueba web.

Cuando uno de los desarrolladores ahora entra en vivo, recibe todos los cambios (posiblemente sin terminar).

Pensé en cambiar en vivo a una rama adicional y fusionar lo que cambió, pero debido a mi falta de conocimiento git, no tengo idea de cómo.

Mi idea es:

  • Cree una nueva sucursal en live ( git branch live).
  • Cada vez que algo tiene que ir a vivir
    • Cambios tirar de maestro (como: git checkout master; git pull; git checkout live)
    • git merge master

El problema es que cambiar a maestro o arrastrar todo directamente al sistema en vivo causaría problemas, por lo que preferiría evitar esto.

¿Hay alguna manera de hacer esto o hay una mejor manera de administrar el sistema Live (excepto para entrenar a los webbies para que no empujen cosas inacabadas)?

git Morfildur
fuente
git pull --allde forma predeterminada, no extraerá master en vivo, extraerá master y lo fusionará con master, y (si existe en el servidor) extraerá live para combinar en live. ¿Lo intentaste?
Tobias Kienzler
¿Su problema es causado por un archivo que no estaba bajo control de versiones antes de ramificarse en vivo y git-agregado después de la modificación para masterizar más adelante? Eso es lo que me sucedió antes, generalmente debería ser suficiente cambiar el nombre de ese archivo temporalmente, o si no es necesario en vivo , úselo git checkout -fpara ignorar el problema, ¡pero haga una copia de seguridad!
Tobias Kienzler
1
relacionado: stackoverflow.com/questions/3216360/…
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件

Respuestas:

21

Puede usar git stashantes de retirar master y pull, y después de revisar live nuevamente usar git stash pop(o si su git es más viejo, git stash applyy git stash clearsuponiendo que no haya escondido nada más)

Tobias Kienzler
fuente
66
git pull --allbuscará todos los controles remotos, pero aún intentará fusionar una rama (o la rama predeterminada) en la rama actual también.
mipadi
@mipadi sí, pero solo la rama actual en sí misma sin tratar de pagar al maestro y causar el conflicto, ¿no?
Tobias Kienzler
Combinará cualquier rama configurada para fusionarse automáticamente en la rama actual (si dicha rama está configurada).
mipadi
1
@Superole Está documentado como "recuperar todos los controles remotos", que incluye no solo múltiples repositorios, sino también ramas. Aunque en retrospectiva, git fetch --allpodría haber sido una mejor respuesta
Tobias Kienzler
2
@TobiasKienzler Solo le indica a git que busque todos los controles remotos configurados. El caso más común es tener solo un origen remoto con nombre. SI tiene más de un control remoto con la misma rama que su actual, y no están en una relación de avance rápido entre sí, ENTONCES, usar la --allopción le dará una combinación de pulpo de las diferentes versiones de la rama en la actual ! Entonces, mi consejo es que se mantenga alejado a --allmenos que eso sea lo que busca, porque en la mayoría de los otros casos no le dará nada.
Superole
74

Yo era capaz de tirar de cambios origin/masteren mastermientras se trabaja en otra rama mediante el uso de este comando:

git fetch origin master:master
Jeff B
fuente
66
¡Increíble! Exactamente lo que estaba buscando: esto debe documentarse mucho más prominentemente ...
Markus Shepherd
2
Puede encontrar documentación sobre esto aquí: git-scm.com/docs/git-fetch#_examples
c1moore
fetch! =pull
D. Kovács
5

Resuelve el problema primero. No deberían estar presionando a una sucursal a la que no tienen negocios presionando.

Lo que parece estar preguntando sería algo así como

git checkout live
git pull origin master

Esto intentará fusionar el maestro remoto y su rama en vivo.

Josh K
fuente
El problema es que actualmente solo tenemos una rama y realmente no será posible cambiar eso ya que todos están demasiado acostumbrados a SVN y no están dispuestos a aprender las ventajas de algo nuevo. Solo será posible crear una nueva rama en el directorio en vivo. Lo que quiero evitar es fusionar el maestro remoto con la rama en vivo, ya que no puedo evitar que nadie envíe código de depuración, funciones incompletas, errores de sintaxis y cualquier otra cosa al maestro (después de todo, solo soy el desarrollador junior). Aunque gracias por tu sugerencia.
Morfildur
2
@dbeme: Puedes usar tarballs y parches. ;) A menos que estén dispuestos a aprender git (y no es nada difícil ramificarse y fusionarse), tendrás problemas.
Josh K
0

Le recomiendo que cree un repositorio de prueba de git para que todos lo confirmen. Todos los repositorios, incluido su sitio web en vivo, serán clones del repositorio de prueba. De esta manera, cualquiera puede presionar para probar sin tocar el sitio web en vivo. Cuando alguien necesita actualizar el sitio en vivo, puede extraer el sitio en vivo del repositorio de prueba de git. Este flujo de trabajo es bastante similar a SVN. Para mayor flexibilidad, recomiendo usar la rama "en vivo" que usted describe.

Para resumir, el repositorio de git de todos es un clon del repositorio de prueba. El sitio de producción en vivo es solo un clon del repositorio de pruebas también. Alternativamente, las pruebas podrían ser un clon de producción en vivo para que un "empujón git" siempre se mueva hacia la producción.

Otras opciones incluyen agregar la rama "en vivo" a este acuerdo o incluir un repositorio de "puesta en escena" entre las pruebas y la producción. Para mayor seguridad, recomiendo restringir el acceso al live git repo y obligar a las personas a usar un script seguro que haga la producción de pull to live.

canto
fuente