¿Por qué no cometer cambios no resueltos?

El mayor problema que puedo ver es que crea una ventana de confirmaciones donde las cosas se fusionan a medias y (probablemente) no funcionan correctamente. Cuando presione el conjunto final de confirmaciones locales, todas esas confirmaciones intermedias también aparecerán para todos los demás. En el mundo ideal, debería poder tirar de cualquier y el código debería funcionar. Si comienza a cometer en medio de las fusiones, el estado del código no está bien definido.

Una cosa que podrías hacer es hacer confirmaciones locales en tu fusión y luego agruparlas en una gran confirmación cuando presionas (aunque no estoy seguro de cómo (si?) cualquier vcs apoya esto). Si bien esto podría generar algunos de los beneficios que mencionó, no estoy seguro de que valga la pena la complejidad adicional (ya estamos tratando con un área bastante confusa y compleja).

Estoy más familiarizado con Git, así que responderé desde esa perspectiva.

No veo una razón por la que o cualquier buen VCS quiera permitir la confirmación de un archivo sin combinar, especialmente si se trata de un código. Debe mantener el repositorio en un estado coherente, y lo que está sugiriendo violaría la atomicidad de la comisión. Muchos VCS modifican físicamente el archivo para mostrar dónde están los conflictos: Git, SVN y CVS usan > > > > < < < < marcadores de tipo En un VCS con confusiones y fusiones de nivel de repositorio atómico, simplemente habría creado un nodo que no tiene sentido para nadie más que usted. En el desarrollo de software, su proyecto no pudo construir. En el documento de un grupo, nadie sabe qué cambios son correctos.

Ahora, Git proporciona algunas herramientas que podrían facilitar esto, si el tipo de compromiso que sugieres esté permitido. Podría aplastar todos los compromisos de fusión juntos antes de presionar, por ejemplo. Eso termina siendo el mismo que un típico compromiso de fusión.

Preocupaciones específicas sobre su lista de beneficios:

1. Los cambios de fusión reales están en el historial. ¿Por qué necesita información adicional? Los DVCS son muy buenos para limitar los conflictos a áreas confinadas. Una vez que elija qué conjunto de cambios desea conservar, la comparación de la copia del nodo de confirmación de fusión con la copia anterior le dará exactamente esto.
2. Si la combinación era muy grande, podría realizar confirmaciones periódicas. Esta es una preocupación válida, pero en primer lugar no debería llegar aquí. Las sucursales deben estar constantemente introduciendo cambios hacia arriba para que esto nunca suceda. Las herramientas como rebase o cherry-pickking un commit a la vez también pueden ayudarlo aquí en algunas situaciones.
3. Si cometió un error, sería mucho más fácil revertirlo (sin tener que rehacer toda la combinación). Vea más arriba: sus conflictos no deberían convertirse en algo inmanejable.

La única forma en que podría funcionar esta sugerencia es si la rama fuera si toda la fusión fuera atómica: se podrían ver una serie de confirmaciones, pero serían simplemente pasos en una confirmación de combinación más grande que debía tratarse como un nodo en el arbol de compromiso No creo que ningún VCS actual tenga soporte para este tipo de flujo de trabajo, y no creo que sea necesario.

Mi experiencia principal reside en Mercurial, aunque también uso git de forma esporádica.

Mercurial no le impide enviar archivos sin resolver, simplemente lo desalienta . Lo mismo ocurre con empujar antes de tirar cambios que no tienes.

Todo lo que necesitas hacer en Mercurial es, una vez que tengas los archivos de la manera que deseas cometerlos:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

--marcará ... marcará los archivos como resueltos sin preguntarle con la herramienta de combinación. --todos nos encargaremos de seleccionar todos los archivos marcados con conflictos.

Si quieres presionar sin jalar (y, en consecuencia, tener que fusionar los cambios de otros) haz como un Jedi :

hg push --force

El siguiente jugador que tire obtendrá una cabeza +1 (sin juego de palabras)

Estoy seguro de que hay una manera de hacer lo mismo con Git (aunque probablemente sea más complicado).

Cuando me fusiono en git, inmediatamente confirmo todos los cambios (incluidos los conflictos de combinación). Luego, en mis próximos compromisos, resuelvo los conflictos de fusión a través de un editor de texto. Una vez que se resuelven los conflictos, presiono si lo desea.

Honestamente, no entiendo por qué los demás no lo hacen de esta manera, o git no lo hace cumplir.

• El "compromiso de fusión" ahora es un historial limpio de exactamente lo que se necesita fusionar.
• Las siguientes confirmaciones muestran exactamente lo que hizo para resolver los conflictos de combinación.
• Cuando empujas, los conflictos se resuelven y la compilación no se rompe en la punta de la rama.
• En cualquier momento, si arruinas la resolución de conflictos, simplemente puedes volver a uno de los compromisos "post merge" e intentarlo de nuevo.

Un gran inconveniente del flujo de trabajo estándar de resolución de conflictos antes de cometer es que los cambios en su copia local pueden infiltrarse. No se da cuenta de que ha comprometido accidentalmente una clave API o etc.

Mi flujo de trabajo descrito anteriormente evita este problema de copia local, y también permite que los revisores de código examinen (solo) los detalles de su resolución de fusión en una diferencia de confirmación que se ve exactamente como una diferencia de confirmación estándar.

Creo que es mejor presionar pequeños cambios y empujar a menudo, cuando es posible (y por supuesto no siempre), y no confirma el código que no se crea, o es Medio completo (todos cometemos errores, pero no lo hacemos a propósito). También vengo de git, y una de las mejores cosas que creo es el hecho de que puedes tener una copia del repositorio en tu escritorio ... que puedes modificar a tu gusto. Cuando tus grandes cambios hayan terminado, envíalos.

Hacer un montón de código abierto con git, la mayor frustración para mí fue hacer que se ingresara el código a medias en el repositorio, y tratar de hacer una compilación, pero no pude, porque el tipo hizo la mitad del trabajo y dijo "Yo ' Estoy ocupado ahora, lo terminaré en una semana ". Así que acabaría teniendo que desecharlo (lo que molestaría al chico), o tomar el tiempo para terminar e integrarlo completamente.

Supongo que desde mi punto de vista, mantén el medio culo localmente, envía el material bueno por el cable.

No seas esclavo de tus herramientas.

El objetivo de un VCS es permitirle hacer su trabajo. Su trabajo es no para mantener un repositorio local prístino, su trabajo es escribir código. Si cometer temprano y con frecuencia localmente le permite trabajar mejor, hágalo.

No deberías, sin embargo, empujar el código roto hacia arriba.

Porque, fundamentalmente, es una mala idea: lo llevará a un repositorio que está en un estado lamentable (y es imprudente suponer que alguna vez empujará en cualquier lugar, aunque uno diría que siempre debe tener al menos una copia). ).

Puedo ver que, en el caso de una combinación grande / compleja, es posible que desee guardar su trabajo en curso y establecer un punto de referencia, pero aún así estaría dejando el sistema en un estado desordenado que debe resolverse. .

Y hay alternativas: tienes la opción de fusionarte antes que la cabeza, lo que bien puede darte la capacidad de adaptarte a los cambios sin fusiones épicas (o al menos con fusiones más grandes que sean más fáciles de comprender). p>

Este es el caso en el que encuentro que la rebase de git es particularmente útil (sujeto a las advertencias habituales sobre el cambio de base) porque estás repitiendo tus cambios sobre el estado actual para solucionar los conflictos en partes más pequeñas.