remota - La mejor(y más segura) forma de combinar una rama git en master

merge branch to master

Question

Se crea una nueva rama del master , lo llamamos test .

Hay varios desarrolladores que se comprometen a master o crear otras ramas y luego se fusionan en el master .

Digamos que el trabajo en la test demora varios días y desea mantener la test continuamente actualizada con los confirmaciones dentro del master .

Haría git pull origin master desde test .

Pregunta 1: ¿Es este el enfoque correcto? Otros desarrolladores podrían haber trabajado fácilmente en los mismos archivos que yo he trabajado por cierto.

Mi trabajo en la test está terminado y estoy listo para fusionarlo de nuevo para master . Aquí están las dos maneras en que puedo pensar:

UNA:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test

SEGUNDO:

git checkout test
git pull origin master
git checkout master
git merge test

No estoy usando --rebase porque, según tengo entendido, rebase obtendrá los cambios de master y stack mine además de que podría sobrescribir los cambios que otras personas hicieron.

Pregunta 2: ¿Cuál de estos dos métodos es correcto? ¿Cuál es la diferencia allí?

El objetivo de todo esto es mantener mi rama de test actualizada con las cosas que suceden en el master y más tarde podría fusionarlas de nuevo con el master con la esperanza de mantener la línea de tiempo lo más lineal posible.

Answer 1

Además de la respuesta de KingCrunches , sugiero utilizar

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Es posible que haya realizado muchas confirmaciones en la otra rama, que solo debe ser una confirmación en la rama maestra. Para mantener el historial de confirmación lo más limpio posible, es posible que desee aplastar todas sus confirmaciones de la rama de prueba en una confirmación en la rama maestra (vea también: Git: ¿Aplastar o no aplastar? ). Luego también puedes reescribir el mensaje de confirmación a algo muy expresivo. Algo que es fácil de leer y entender, sin profundizar en el código.

edición: usted podría estar interesado en

• En git, ¿cuál es la diferencia entre fusionar --squash y rebase?
• Fusionando vs. Rebasando
• Cómo reajustar una solicitud de extracción

Así que en GitHub, termino haciendo lo siguiente para una rama de mybranch :

Recibe lo último de origen

$ git checkout master
$ git pull origin master

Encuentra el hash base de fusión:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f
$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Ahora asegúrese de que solo la primera es la pick , el resto es s :

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

A continuación, elija un mensaje de confirmación muy bueno y presione para GitHub. Haga la solicitud de extracción entonces.

Después de la combinación de la solicitud de extracción, puede eliminarla localmente:

$ git branch -d mybranch

y en GitHub

$ git push origin :mybranch

Answer 2

Como yo haria esto

git checkout master
git pull origin master
git merge test
git push origin master

Si tengo una sucursal local desde una remota, no me siento cómodo combinando otras sucursales que esta con la remota. Además, no presionaría mis cambios, hasta que esté satisfecho con lo que quiero promover y tampoco presionaría las cosas, eso es solo para mí y para mi repositorio local. En su descripción parece, esa test es solo para usted? Así que no hay razón para publicarlo.

git siempre trata de respetar los cambios tuyos y de otros, y así lo hará --rebase . No creo que pueda explicarlo adecuadamente, así que eche un vistazo al libro de Git - Rebasar o listo para git: Introducción a la rebasada para una pequeña descripción. Es una característica bastante genial

Answer 3

Esta es una pregunta muy práctica, pero todas las respuestas anteriores no son prácticas.

Me gusta

git checkout master
git pull origin master
git merge test
git push origin master

Este enfoque tiene dos problemas :

1. No es seguro, porque no sabemos si hay algún conflicto entre la rama de prueba y la rama maestra.

2. Esto "exprimiría" todas las confirmaciones de prueba en una única fusión en el maestro; es decir, en la rama maestra, no podemos ver todos los registros de cambios de la rama de prueba.

Entonces, cuando sospechamos que habría algunos conflictos, podemos tener las siguientes operaciones de git:

git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test

Pruebe la merge antes de commit , evite un commit rápido por --no-ff ,

Si se encuentra un conflicto, podemos ejecutar el git status para verificar los detalles de los conflictos y tratar de resolverlos.

git status

Una vez que resolvemos los conflictos, o si no hay conflicto, los commit y push

git commit -m ''merge test branch''
git push

Pero de esta manera perderá el historial de cambios registrado en la rama de prueba, y haría que la rama maestra sea difícil para otros desarrolladores comprender el historial del proyecto.

Entonces, el mejor método es utilizar rebase lugar de merge (supongamos que, cuando en este momento, hemos resuelto los conflictos de rama).

A continuación se muestra una muestra simple, para operaciones avanzadas, consulte http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Sí, cuando haya terminado, todas las confirmaciones de la rama de prueba se moverán a la cabeza de la rama maestra. El mayor beneficio de la rebasación es que obtiene un historial de proyecto lineal y mucho más limpio.

Lo único que debe evitar es: nunca use rebase en una sucursal pública, como una rama maestra.

Nunca realice operaciones como las siguientes:

git checkout master
git rebase -i test

Detalles para https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

apéndice:

• Si no está seguro acerca de las operaciones de rebasado, consulte: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Answer 4

Este es el flujo de trabajo que uso en mi trabajo con el equipo. El escenario es como lo describiste. Primero, cuando termine de trabajar en la test me reagrupo con el maestro para extraer todo lo que se haya agregado al maestro durante el tiempo que he estado trabajando en la rama de test .

git pull -r upstream master

Esto llevará a los cambios al maestro ya que bifurcó la rama de test y los aplicó, y luego aplicará los cambios que haya realizado para probar "sobre" el estado actual del maestro. Puede haber conflictos aquí, si las otras personas han realizado cambios en los mismos archivos que ha editado en la prueba. Si los hay, deberás arreglarlos manualmente, y confirmar. Una vez que haya hecho eso, será bueno cambiar a la rama maestra y combinar la test sin problemas.

Answer 5

Hilo viejo, pero no he encontrado mi forma de hacerlo. Podría ser valioso para alguien que trabaja con rebase y desea combinar todos los compromisos de una rama en la parte superior del maestro. Si hay un conflicto en el camino, puede resolverlos para cada compromiso.

Obtener Master y sucursal al día:

git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>

Fusionar rama sobre maestro:

git checkout <branch_name>
git rebase master
git add .
git rebase continue

Si te topas con conflictos durante la Rebase:

En primer lugar, resolver el conflicto en el archivo. Entonces:

git add .
git rebase --continue

Una vez finalizado el rebase, rebase rama en la parte superior del maestro

git checkout master
git rebase <branch_name>

Answer 6

Ni una rebase ni una fusión deben sobrescribir los cambios de nadie (a menos que elija hacerlo al resolver un conflicto).

El enfoque habitual durante el desarrollo es

git checkout master
git pull
git checkout test
git log master.. # if you''re curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Cuando estés listo para volver a unirte al maestro,

git checkout master
git log ..test # if you''re curious
git merge test
git push

Si estás preocupado por romper algo en la fusión, git merge --abort está ahí para ti.

El uso de empujar y luego tirar como un medio de fusión es una tontería. Tampoco estoy seguro de por qué estás empujando la prueba al origen.

Answer 7

Yo usaría el método de rebase. Sobre todo porque refleja perfectamente su caso semánticamente, es decir. lo que quiere hacer es actualizar el estado de su rama actual y "simular" como si estuviera basado en lo último.

Así que, sin siquiera echarle un vistazo al master , yo:

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

Por supuesto, solo recuperar el origen no actualiza el estado local de su master (ya que no realiza una fusión), pero está perfectamente bien para nuestro propósito: queremos evitar el cambio, para ahorrar tiempo.

Answer 8

git checkout master
git pull origin master
# Merge branch test into master
git merge test

Después de fusionar, si se cambia el archivo, cuando lo fusione se producirá el error "Resolver conflicto"

Entonces, primero debe resolver todos sus conflictos, luego debe volver a confirmar todos los cambios y luego presionar

git push origin master

Esto es mejor hacer quién ha hecho cambios en la rama de prueba, porque sabía qué cambios ha hecho.