git - Cómo evitar que el fachador coman mi historial de compromisos
github phabricator (5)
Aquí está el escenario que me resulta bastante molesto.
Jack trabaja en foobar, una casa de software, Jack es un programador de trabajo , le encanta codificar y se compromete con frecuencia. Paul, que es el gerente de Jack, le dice que vamos a comenzar a usar una nueva herramienta de revisión de código, phabricator. Jack cumple, Jack crea una sucursal local y comienza a trabajar. Agrega características y compromisos a su sucursal local con mucha frecuencia. Ahora, al final del día, envía una solicitud de fachador.
arc diff development
John, que es miembro del equipo de Jacks, revisa su código y acepta sus cambios. Ahora Jack abre la terminal y se mueve a su directorio de repositorio. Jack escribe el siguiente comando para cerrar la revisión y fusionar su código con la rama de desarrollo.
arc land --onto development
Él ve el siguiente mensaje
Landing current branch ''feature-awesome-features''.
Switched to branch development. Updating branch...
The following commit(s) will be landed:
b2ff76e Added the foo to bar
33f33ba Added a really important check which can destroy the project or save it
31a4c9a Added that new awesome feature
8cae3bf rewrote that awful code john wrote
bc54afb bug fixes
Switched to branch feature-awesome-features. Identifying and merging...
Landing revision ''D1067: Added the awesome feature''...
Rebasing feature-awesome-features onto development
Already up-to-date.
Pushing change...
Ahora Jack abre Github para ver su código, sus hermosos compromisos. pero lo que ve es puro horror, todos sus compromisos han sido reemplazados por un único compromiso que básicamente dice algo como esto
Summary: Added the awesome feature
Test Plan: do foo bar testing
Reviewers: John
Reviewed By: John
CC: Paul
Differential Revision: http://phabricator.foobar.com/D1067
Ahora Jack está triste, porque quiere ver todas sus acometidas, Jack cree que este compromiso lo hace lucir como The Hoarder, que no es. Él quiere arreglar esto, así que va a hacer una pregunta sobre stackoverflow.
That how may he prevent phabricator from eating his commit history.
--merge no funciona ya que crea un commit de fusión. He parcheado el mío para tener una --rebase que hará lo correcto, pero no estoy seguro de si a la gente del arco le gustaría tener esto.
Deberías usar el flujo de git nativo como git merge y git push directamente en su lugar. De la documentación del arco del fabricante:
Después de que se hayan aceptado los cambios, generalmente los presiona y cierra la revisión. arco tiene varios flujos de trabajo que ayudan con esto, por:
* squashing or merging changes from a feature branch into a master branch * formatting a good commit message with all the information from Differential * and automatically closing the revision.No necesita usar ninguno de estos flujos de trabajo: simplemente puede ejecutar git push, hg push o svn commit y luego cerrar manualmente la revisión desde la web.
arc está aplastando sus compromisos a propósito.
Existe alguna documentación que explica por qué esta es la configuración predeterminada para arc land .
Una estrategia en la que una idea es una confirmación no tiene ninguna ventaja real sobre ninguna otra estrategia hasta que su repositorio alcance una velocidad donde se vuelva crítica. En particular:
- Esencialmente, todas las operaciones contra el repositorio maestro / remoto son sobre ideas, no compromisos. Cuando una idea son muchas confirmaciones, todo lo que haces es más complicado porque necesitas descubrir qué confirmaciones representan una idea ("el widget foo está roto, ¿qué debo revertir?") O qué idea se representa finalmente mediante una confirmación ("commit af3291029 no tiene sentido, ¿qué objetivo está tratando de lograr este cambio?").
- La ingeniería de lanzamiento se simplifica enormemente. Los ingenieros de lanzamiento pueden elegir o soltar ideas fácilmente cuando cada idea corresponde a una confirmación. Cuando una idea implica varias confirmaciones, resulta más fácil seleccionar o eliminar la mitad de una idea accidentalmente y terminar en un estado que virtualmente está garantizado que es incorrecto.
- Las pruebas automatizadas se simplifican enormemente. Si cada idea es una confirmación, puede ejecutar pruebas automatizadas contra cada confirmación y las fallas de prueba indican un problema grave. Si cada idea implica muchas confirmaciones, la mayoría de esas confirmaciones representan un estado roto conocido de la base de código (por ejemplo, un punto de control con un error de sintaxis que se corrigió en el siguiente punto de control o con una idea a medio implementar).
- Comprender los cambios se simplifica enormemente. Puede dividirse en dos e identificar la idea de manera trivial, sin tener que ir hacia adelante y hacia atrás en el registro para identificar el alcance de la idea. Y puede tener confianza en lo que necesita revertir para eliminar toda la idea.
- No existe un valor claro para que persista en el control remoto el compromiso de puntos de control (algunos de los cuales se garantiza que se conocen como versiones rotas del repositorio). Considere un VCS teórico que crea automáticamente una confirmación de punto de control para cada pulsación de tecla. Este VCS obviamente sería inutilizable. Pero muchos commits de puntos de control no son muy diferentes, y conceptualmente representan algún punto relativamente arbitrario en la secuencia de pulsaciones de teclas que entró en la escritura de una idea más grande. Deshágase de ellos o cree una capa de abstracción (merge commits) que le permita ignorarlos cuando intente comprender el repositorio en términos de ideas (que es casi siempre).
Todos estos se convierten en problemas solo a escala. Facebook empuja decenas de ideas todos los días y miles semanalmente, y no podría hacer esto (al menos, no sin más personas o más errores) sin elegir una estrategia de repositorio donde una idea es una confirmación.
Para git, la solución recomendada es insertar ramas de características en el flujo ascendente, luego fusionar en lugar de volver a establecer la base en el maestro, si está de acuerdo con los puntos anteriores pero aún quiere que su punto de control se comprometa en el flujo ascendente.
Si esto es solo durante la revisión (ya que su pregunta está redactada, pero también parece que no está revisando el código o revisando el código solo con Audit), tenga en cuenta que Diferencial ya mostrará todas sus confirmaciones locales con el original. cometer un mensaje para que el revisor lo vea.
arc land está diseñado para usarse solo para avanzar a la rama "final" de un repositorio (es decir, producción o alguna rama que represente cambios pendientes de publicación). Si está realizando una revisión de confirmación posterior al envío (es decir, en las fusiones entre el desarrollo y el máster), puede omitir el arc land (y generalmente se acepta que debe hacerlo en muchos casos) y git push sus cambios directamente.
La respuesta de Asherkin explica la razón de este comportamiento y por qué es el predeterminado.
Si no encuentra convincente ese argumento, puede usar el indicador --merge para arc land --no-ff --squash lugar de --squash . Estas fusiones no destruirán las confirmaciones locales.
Si configura history.immutable en true en su .arcconfig , arc land se fusionará --no-ff de forma predeterminada.
También puede usar comandos raw git si no le gusta el comportamiento de arc land de arc land ; se proporciona solo por conveniencia.
En su ejemplo, recomendamos crear cinco revisiones separadas : hay múltiples ideas diferentes que se implementan, y no están relacionadas y parecen fáciles de separar. Vea Escribir código revisable . La combinación de soluciones de errores, cambios de estilo y nuevas características en un cambio es acumulativa.
history.immutable: configura el arco para usar flujos de trabajo que nunca reescriben el historial en la copia de trabajo. De forma predeterminada, el arco realizará algunas reescrituras del historial no publicado (modificando los mensajes de confirmación, la fusión squash) en algunos flujos de trabajo en Git. Las distinciones se tratan en detalle a continuación.
así que solo agregue línea en su .arcconfig
"history.immutable": true