¿Cuál es la mejor (y más segura) forma de combinar una rama Git en un asistente?

Una nueva rama se crea desde el master , lo llamamos test .

Hay varios desarrolladores que se transfieren al master o crean otras ramas y luego se fusionan con el master .

Supongamos que el trabajo en la test demora varios días y desea actualizar constantemente la test utilizando confirmaciones dentro del master .

Haría un git pull origin master desde test .

Pregunta 1: ¿Es esto correcto? Otros desarrolladores podrían trabajar fácilmente con los mismos archivos con los que trabajé. Por cierto


Mi trabajo en la test está ejecutando, y estoy listo para fusionarlo con el master nuevamente. Aquí hay dos maneras en que puedo pensar:

A:

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

B:

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

No uso --rebase porque, en mi opinión, rebase recibirá los cambios del master y pondrá el mío por encima de esto, por lo que puede sobrescribir los cambios realizados por otras personas.

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

El objetivo es mantener la rama de test actualizada con las cosas que están sucediendo en el master , y luego puedo fusionarlas de nuevo con el master , con la esperanza de mantener la gráfica lo más lineal posible.

1682
09 апр. establecer moe 09 de abril. 2011-04-09 03:01 '11 a las 3:01 2011-04-09 03:01
@ 9 respuestas

Como lo haria

 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 al fusionar otras sucursales que con una remota. Además, no insistiría en mis cambios hasta que esté satisfecho con lo que quiero presionar, y además no insistiría en nada, esto es solo para mí y para mi repositorio local. En tu descripción, ¿parece que la test solo para ti? Por lo tanto, no hay razón para publicarlo.

git siempre está tratando de respetar tus y otros cambios, y también lo hará --rebase . No creo que pueda explicarlo correctamente, así que mire el libro Git-Rebasing o el libro git-ready: una introducción a un reinicio para una breve descripción. Esta es una característica muy buena.

2477
09 апр. La respuesta se da KingCrunch 09 abr. 2011-04-09 03:45 '11 a las 3:45 am 2011-04-09 03:45

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

como

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

Este enfoque tiene dos preguntas :

  1. Esto no es seguro porque no sabemos si hay algún conflicto entre la rama de prueba y la rama principal.

  2. Él "exprimió" todas las pruebas comprometidas en una unión de fusión en el maestro; es decir, en la rama principal, no podemos ver todos los registros de cambios de la rama de prueba.

Por lo tanto, cuando sospechamos que surgirán algunos conflictos, podemos realizar las siguientes operaciones de git:

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

Drene la merge pruebas antes de commit , evite el reenvío rápido con --no-ff ,

Si ocurre un conflicto, podemos ejecutar el git status para verificar la información del conflicto y tratar de resolver

 git status 

Cuando resolvemos conflictos o si no hay conflicto, los commit y push .

 git commit -m 'merge test branch' git push 
border=0

Pero este método perderá el historial de cambios registrados en la rama de prueba, y esto hará que la rama principal sea difícil para que otros desarrolladores entiendan el historial del proyecto.

Por lo tanto, el mejor método es usar rebase lugar de merge (supongamos que, cuando en este momento rebase conflictos de rama).

A continuación se muestra un ejemplo simple, para operaciones extendidas, 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 llegues a la parte superior, todos los exámenes finales se transferirán a la rama principal del maestro. La principal ventaja de la recuperación es que obtiene un historial de proyecto lineal y más limpio.

Lo único que debe evitar: nunca utilice una rebase en una sucursal pública como una sucursal maestra.

Nunca realice las siguientes operaciones :

 git checkout master git rebase -i test 

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

aplicación:

304
14 марта '15 в 15:13 2015-03-14 15:13 John Yin da la respuesta el 14 de marzo de 2015 a las 15:13 2015-03-14 15:13

Ni rebid ni merge deben sobrescribir los cambios a nadie (a menos que decida hacerlo al resolver un conflicto).

El enfoque habitual al desarrollar.

 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 unirte en el maestro,

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

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

El uso de empujar y luego tirar, como un medio de fusión, es una estupidez. Tampoco sé por qué presionas la prueba de origen.

80
10 апр. respuesta dada raylu 10 abr 2011-04-10 03:17 '11 a las 3:17 2011-04-10 03:17

Primero, haría la rama fina más alta posible. Ejecute sus pruebas, asegúrese de que el estado es lo que desea que sea. Limpiar nuevos git squash .

Además de la respuesta de KingCrunches , sugiero usar

 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 otra rama, que debería ser solo una confirmación en la rama principal. Para mantener el historial de confirmación lo más limpio posible, es posible que deba aplastar todas sus confirmaciones de la rama de prueba en una fijación en la rama principal (consulte También: ¿ Git: Squash 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 escarbar en el código.

Edit: Usted puede estar interesado

Entonces en GitHub, termino haciendo lo siguiente para la mybranch función mybranch :

Obtenga los últimos datos de la fuente

 $ git checkout master $ git pull origin master 

Encuentra el hash de fusión:

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

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

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

Luego seleccione un mensaje de confirmación muy bueno y haga clic en GitHub. Luego haz una solicitud de estiramiento.

Después de fusionar una solicitud de recuperación, puede eliminarla localmente:

 $ git branch -d mybranch 

y en github

 $ git push origin :mybranch 
30
21 апр. respuesta dada por Martin Thoma 21 de abril 2016-04-21 11:18 '16 a las 11:18 2016-04-21 11:18

Este es un flujo de trabajo que utilizo en mi trabajo con el equipo. Guión como lo describe. Primero, cuando terminé de trabajar en la test , reinstalo el asistente para extraer todo lo que se agregó al asistente mientras estaba trabajando en la rama de test .

git pull -r upstream master

Esto conducirá a cambios en el maestro, ya que se ramifica fuera de la rama de test y los aplica, y luego aplica los cambios realizados para verificar el estado actual del asistente. Puede haber conflictos si otras personas realizaron cambios en los mismos archivos que editó en la prueba. Si lo hay, deberás corregirlos manualmente y confirmar. Después de hacer esto, será útil cambiar a la rama principal y combinar la test sin problemas.

4
17 марта '16 в 1:27 2016-03-17 01:27 la respuesta se da djheru 17 de marzo de 2016 a las 1:27 2016-03-17 01:27
 git checkout master git pull origin master # Merge branch test into master git merge test 

Después de la fusión, si se modifica el archivo, al fusionarlo se producirá el error "Resolver conflicto"

Entonces, primero debe resolver todos sus conflictos, luego debe hacer todos los cambios nuevamente y luego hacer clic en

 git push origin master 

Es mejor que haya hecho cambios en la rama de prueba, porque él sabía qué cambios hizo.

1
07 апр. La respuesta la da Vinay Sikarwar 07 abr. 2015-04-07 11:55 '15 a las 11:55 2015-04-07 11:55

Hilo viejo, pero no he encontrado una manera de hacerlo. Esto puede ser útil para aquellos que trabajan con rebase y desean combinar todas las confirmaciones de la rama en la parte superior del asistente. Si hay un conflicto, puede resolverlos para cada confirmación.

Actualiza el master y la sucursal:

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

Combina la rama en la parte superior del asistente:

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

Si encuentra conflictos durante Rebase:

Primero, resuelva el conflicto en el archivo. Entonces

 git add . git rebase --continue 

Una vez que se complete la rebase, mueva la rama sobre el asistente:

 git checkout master git rebase <branch_name> 
1
31 окт. La respuesta la da Robin Wieruch el 31 de octubre. 2018-10-31 07:14 '18 a las 7:14 2018-10-31 07:14

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

Por lo tanto, sin siquiera revisar el master , yo:

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

Por supuesto, solo una muestra de la fuente no actualiza el estado local de su master (ya que no se fusiona), pero esto es completamente normal para nuestro propósito: queremos evitar el cambio para ahorrar tiempo.

1
13 сент. La respuesta la da el usuario 776686 13 de septiembre. 2018-09-13 10:13 '18 a las 10:13 pm 2018-09-13 10:13

Es fácil, solo sigue estos pasos.

  • Asistente de pago de Git
  • Git fusionar
  • Botón Git del principio del OR original. Si lanza algún error, también puede forzarlo.

Git Click Start Wizard

Que es

-38
03 дек. La respuesta la da Vinay Sikarwar 03 dic. 2017-12-03 06:28 '17 a las 6:28 2017-12-03 06:28