solicitudes de extracción de combinación contra rebase en github

7

Estoy trabajando activamente en un proyecto para dos personas con muy pocas sucursales de larga data (la sucursal más larga es de 3 semanas).

He pasado la tarde tratando de comprender fusionar vs rebase y cuáles son las ventajas y desventajas. He hecho algunos progresos y planeo incorporar rebase para limpiar mis compromisos locales antes de presionar a github para una revisión del código. Me gusta cometer a menudo y he realizado pruebas automáticas, por lo que parece que el principal argumento en contra de la rebase de que podría introducir errores en las confirmaciones rebasadas no es tan relevante. Si bien he visto algunos argumentos en contra de este tipo de rebasado, parece menos controvertido. Una vez que se completa la revisión del código, mi confusión es acerca de la rebasación frente a la combinación de una rama de función en el maestro. Sé que nadie más está confiando en él y el proceso de revisión del código generó muchos pequeños sintaxis sin sentido. Ambos parecen sugerir una reorganización.

Tengo entendido que para mi proyecto, la reorganización tiene la ventaja de mantener limpio el historial, lo que me permite ver mejores resúmenes en los que no se ha introducido un cambio. También ayuda a mantener el historial lineal, lo que facilita el uso de git bisect (se trata de que el historial sea lineal o de que cada compromiso sea completo y no se rompa intencionalmente). También permite correcciones a mi ejemplo actual donde olvidé cambiar el nombre y editar un archivo en confirmaciones separadas antes de enviar una solicitud de extracción, lo que lleva a una gran diferencia innecesaria. Para este proyecto, ninguno de estos parece ser una desventaja de cambio de juego al usar el flujo de trabajo de git-merge (el código base puede que aún no sea lo suficientemente grande como para experimentar las desventajas reales), pero sería bueno tenerlo si no hay grandes desventajas.

Las desventajas que veo son que no soy un experto en git y parece mucho más fácil realmente romper las cosas con rebase que con merge. En segundo lugar, hacemos muchos comentarios activos sobre las solicitudes de extracción en github y tengo dudas de romper o perder esos comentarios al rebasar y cambiar el SHA (pensándolo bien, no creo que pierda los comentarios, pero ya no me refiero a las confirmaciones correctas, por lo que tendría que buscar las confirmaciones mencionadas por otros medios). En tercer lugar, da la ilusión de que cada compromiso es un compromiso lógico completo y de trabajo cuando en realidad es probable que todavía tenga compromisos que están parcialmente rotos.

En este artículo sobre merge vs rebase, dan el Siguiendo los consejos sobre esta situación:

  

La revisión está lista y lista para integrarse en la rama de destino.   ¡Felicidades! Estás a punto de eliminar tu rama de características. Dado   que otros desarrolladores no se fusionarán en estos cambios desde   En este punto, esta es tu oportunidad de desinfectar la historia. En este punto   Puedes reescribir la historia y doblar los compromisos originales y los molestos   "Re-rework" y "merge" se comprometen en un pequeño conjunto de compromisos enfocados.   Crear una fusión explícita para estos compromisos es opcional, pero tiene   valor. Se registra cuando la función se graduó a maestro.

Estoy muy interesado en saber si mi análisis anterior está en el camino correcto. En este momento me estoy inclinando hacia el uso prudente de rebase como se describe en el consejo anterior. Pero incluso estoy confundido sobre cómo hacer realmente lo que sugieren. ¿Cómo creo una fusión explícita? ¿Hago una sucursal local que sea una copia de feature y luego rebase -i en esa rama para que el historial parezca que quiero y luego se fusione con el maestro? O rebase feature directamente en el maestro y luego uso rebase -i para aplastar las confirmaciones según corresponda. Si este enfoque es lo que están sugiriendo, ¿cómo puedo crear una fusión explícita al final?

    
pregunta emschorsch 12.02.2016 - 02:55

2 respuestas

3

La solución que decidí era la más sencilla y la que más ventajas tenía para mí era volver a generar y luego fusionar. Después de usar github para avanzar y retroceder en la solicitud de extracción y realizar algunos cambios menores, llegó el momento de fusionarla en la rama principal. En mi configuración local lo hice:

git pull
git checkout feature
git rebase -i HEAD~8  # combine small commits and separate file moving
git checkout master
git merge --no-ff feature  # comment this with 'close #<pull_request_number>'
git push

Las ventajas son:

  • En la rama maestra, el historial es más limpio y conciso
  • La fusión explícita al final vincula la solicitud de extracción con el compromiso de fusión

Las desventajas son:

  • Las confirmaciones rebasadas en la solicitud de extracción ya no enlazan con las confirmaciones en el maestro, lo que podría ser confuso.
  • En realidad, no regresé y me aseguré de que cada una de las confirmaciones rebasadas funcione en el nuevo contexto, por lo que hay pocas posibilidades de que haya errores allí

No estoy seguro si este es un enfoque recomendado o un poco demasiado intrépido y debería atenerme a uno u otro. Pero veremos si hay algún problema derivado de esto. Sin embargo, muy flexible para diferentes sugerencias de otras personas.

    
respondido por el emschorsch 13.02.2016 - 21:12
1

Veo que ya has respondido la pregunta con tu propia respuesta, pero todavía tengo ganas de compartir esto.

Hasta que ingreses al repositorio remoto, realmente no importa si usas merge o rebase . Ya has señalado, que con rebase , los rieles de derivación se ven más limpios, porque se mantienen lineales y no se extienden como lo hacen con merge .

De cualquier manera, al usar tanto rebase como merge , es probable que se vea obligado a solucionar los conflictos y estos conflictos pueden y pueden ser completamente diferentes.

Por lo tanto, si está trabajando solo en una rama (esta rama no se puede enviar al repositorio remoto todavía), sugeriría hacer rebasing antes de la solicitud de extracción inicial. Si la rama permanece en el repositorio y si alguna vez vuelves a trabajar en ella, merge es el camino a seguir, ya que rebase se metería con el historial de las sucursales discutidas y los diferentes desarrolladores podrían tener un código diferente.

    
respondido por el Andy 13.02.2016 - 22:42

Lea otras preguntas en las etiquetas