¿Por qué no cometerías cambios combinados inmediatamente?


16

Mi oficina usa Git y SourceTree para nuestro control de versiones. Esto ocurrió porque cuando me uní, no había control de versión y SourceTree era el único sistema que había usado. No soy un experto de ninguna manera, pero soy el más experimentado de mis compañeros de trabajo, así que soy el experto de facto responsable de enseñar a todos a usar Git correctamente y corregir los errores que están cometiendo.

Estoy haciendo un documento tutorial que pasa por Git y SourceTree y explica cada paso del proceso. En el proceso de extracción, el diálogo de SourceTree le permite seleccionar la opción "Confirmar cambios combinados inmediatamente". Entiendo lo que hace y por qué es útil. Lo que no entiendo es por qué alguien no querría usar esta función.

¿Alguien podría explicar por qué no querrías que tus cambios combinados se confirmen automáticamente? Estoy tratando de entender el razonamiento para poder explicar mejor la utilidad de la función y tener una idea de los escollos a tener en cuenta en el futuro.

Editar: no creo que mi pregunta sea un duplicado de la pregunta vinculada. La pregunta vinculada es, en general, preguntar con qué frecuencia cometer. Me pregunto por qué uno elegiría no usar una función específica relacionada con la confirmación de fusiones en SourceTree.



1
¿Quieres buenas razones? Porque puedo proporcionar una variedad de razones para retrasar la verificación del código que escuché decir a la gente en la naturaleza, pero pocas de ellas son buenas razones.
whatsisname

La única razón por la que puedo pensar es cuando una fusión falla debido a conflictos de fusión. Pero SourceTree no se comprometerá si eso sucede de todos modos.
Robert Harvey

En una nota al margen: ¿Por qué estás escribiendo tu propio tutorial? Bitbucket ya tiene un gran tutorial. confluence.atlassian.com/bitbucket/…
winkbrace

@winkbrace No estamos usando Bitbucket; Mantenemos todo en una red local. Hago referencia al gran tutorial de Atlassian , pero quería algo un poco más conciso que pudiera ofrecer a las personas que eran nuevas en Git y el control de versiones. Realmente es más una introducción y un procedimiento "así es como y por qué se compromete / empuja / tira / etc" para que la gente pueda comenzar a ejecutar.
David K

Respuestas:


26

No me gustaría usar esta función.

El hecho de que no haya conflictos significa que los cambios que se fusionan en mi rama no están en las mismas líneas de código que los que he realizado. No significa que esos cambios sean compatibles con mis cambios. No significa que el código se compilará, o que el código funcionará, o que las pruebas pasarán.

En otras palabras, al usar esta opción, potencialmente termino con una confirmación falsa de código que puede no estar en un buen estado y que requiere una nueva confirmación para solucionarlo. Como lo estoy haciendo este trabajo de todos modos, y ya que nunca debería impulsar esta espuria cometer aguas arriba, ni siquiera por error (Bondad lo quiera, alguien puede luego fusionar que en alguna otra rama!), No veo ninguna razón para crear esta comprometerse en la primera sitio.


Presumiblemente, está creando ramas de características y no combina cada pequeño cambio en la rama principal. Es improbable que las fusiones causen conflictos en una rama de características a menos que varias personas estén trabajando en la misma clase en la misma rama de características.
Robert Harvey

44
@RobertHarvey Sí, pero presumiblemente fusiono frecuentemente la rama principal con mi rama. Hay un supuesto oculto en su comentario de que las diferentes características tocarán naturalmente diferentes clases / módulos, pero no todos tienen suerte. Por (mala) fortuna tienes una clase de Dios en algún lugar que todos los que hacen algo necesitan tocar, y no puedes hacer mucho al respecto. También hay características transversales (actualice alguna biblioteca porque una de cada 10 líneas de código necesita cambiar ...) Conozco el argumento "tratar de no llegar", pero ¿qué pasa si ya está allí? Más vale prevenir que lamentar.

2

Después de una fusión, puede haber cambios en los archivos en el repositorio local. Estos cambios no se confirman automáticamente en el local, a menos que establezca "Confirmar cambios combinados inmediatamente".

Si no configura esa opción, los archivos aparecen en SourceTree como cambios no confirmados.

Esto se debe a que Git en sí no se compromete a menos que se lo indique explícitamente, y SourceTree es una GUI de Git. La opción "Confirmar cambios combinados inmediatamente" no es tanto una opción, sino un atajo de comando.

Por lo tanto, la razón por la que no desea utilizar esta función es evidente: desea realizar la confirmación manualmente, o no hacer nada.

Digamos que llevas el master a tu rama de características. Un compañero de trabajo está trabajando en una rama de características diferente. Este compañero de trabajo tiene una historia de romper cosas. La fusión contiene cambios en el código común compartido realizado por este compañero de trabajo. Entonces, usted, junto con el resto del equipo, no comete cambios combinados hasta que esté seguro de que este compañero de trabajo no hará cambios que afecten su trabajo.

El hecho de que no haya una buena razón, en teoría, para no usar esta función, en realidad, puede haber varias buenas razones. Con respecto a su tutorial, solo diría que "99 de cada 100, esta es la opción que desea usar". No creo que realmente necesite entrar en detalles sobre no usarlo, especialmente si los otros son nuevos en el control de versiones. Todo depende de cuán profundo pretendas que sea el tutorial.


2

Si está utilizando un enlace post commit para impulsar automáticamente sus commits (como en /programming//a/7925891/6781678 ), es posible que necesite esta opción para evitar empujar algunos commit de dudosa calidad.

Yo nunca usaría tampoco.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.