Puesta en escena de Git: ¿Cuándo actuar? Qué hacer si la modificación ocurre después

Soy bastante nuevo en el amplio mundo de Git. He leído el manual y he estado practicando, pero estoy confundido acerca de algunos aspectos del mismo, que no pude entender después de buscar.

Me pregunto:

• En un proyecto (post first commit), ¿cuándo es el momento adecuado para organizar los archivos fuente? Justo antes de comprometerse? ¿Justo después de agregar / eliminar o modificar?

• Si los archivos se organizan a mitad de camino entre dos confirmaciones y luego se modifican, ¿qué sucede con Git? ¿Es necesario preocuparse por los cambios de contenido cuando se declaró y en qué se convirtió desde entonces?

• Si creo un nuevo archivo, lo organizo y luego quiero eliminarlo, ¿por qué Git me pide que use el indicador "-f" y un simple "git -rm file.ext" no funcionará?

He leído "Qué significa etapa" y varias otras materias del manual y otros tutoriales sobre Git, pero como dije, todavía no entiendo los asuntos anteriores.

Entonces, si pudiera, responda las preguntas con sus propias palabras y ejemplos para que tenga una mejor oportunidad de entenderlo.

Gracias.

El propósito del área de preparación es tener un espacio flexible para su compromiso. Creo que esto se aclarará si contrasta git con los sistemas de control de versiones que están centralizados, como la subversión.

Subversión

En subversion puede seleccionar confirmar ciertos archivos de su copia de trabajo. Pero solo los archivos completos. Ahora: ¿Qué sucede si desea organizar el archivo A, no el archivo B, y las partes del archivo Cque se relacionan con el archivo Apero no las partes que dependen de los cambios en el archivo B(desde entonces tendría un problema con la coherencia de confirmación).

Git

Git resuelve esto al proporcionar la puesta en escena como una segunda copia de trabajo. Dentro del área de preparación, está armando una instantánea que se comprometerá (más o menos).

Por lo tanto, dentro del área de preparación puede crear una instantánea que incluya cambios Ay una versión del archivo Cque solo refleje los cambios A.

Para las preguntas específicas

• Puede organizar en cualquier momento que desee. Personalmente prefiero actuar justo antes de lanzar el commit.

• Al realizar cambios en un archivo por etapas y luego cambiar ese archivo en la copia de trabajo, no ha alterado el archivo por etapas, por supuesto. Usted puede decidir si organizar esos también o si no realizar esos cambios. Es decir, si ejecuta git gui citool, verá diferencias de versiones preparadas y no preparadas (herramientas agradables y simples para la puesta en escena y la confirmación en línea).

• Git es cauteloso aquí, lo que probablemente sea algo bueno.

Estrategia de compromiso general: compromisos granulares

Creo que cuando se habla de la pregunta "¿Cuándo debo presentarme?", También se debe hablar sobre los hábitos de compromiso.

VCS centralizado

En los sistemas de control de versiones centralizados en los que se compromete con un servidor central, era importante para sus compañeros de trabajo que sus confirmaciones estén completas y bien probadas. Por lo tanto, las personas intentarían cometer no tan a menudo y luego confirmar el estado de los archivos completos para minimizar la posibilidad de un error. Por lo tanto, las confirmaciones tienden a ser fragmentos bastante grandes que incluyen muchos cambios (si no son soluciones simples). Los cambios en un commit pueden ser totalmente ajenos.

Git

En Git, una confirmación se realiza localmente, solo enviarlos a un servidor los hace públicos. Por lo tanto, un commit es barato en cierto sentido. Un commit en el sentido de subversión es bastante comparable a varios git commitseguidos de git push. Esta diferencia importa.

Git le permite confirmar líneas de código individuales, incluso si también ha cambiado otras líneas en el mismo archivo. Esto le brinda muchos beneficios, ya que puede, por ejemplo, cometer una corrección de errores de seguridad en la línea 100 al cambiar las líneas 300-350 e introducir una nueva característica.

• Puede separar diferentes cambios en diferentes confirmaciones. Esto los separa muy bien en su historial de versiones e incluso le permite revertir uno pero no el otro.
• Su confirmación no necesariamente tiene que reflejar un estado de "compilación" de su copia de trabajo (aunque trato de mantenerla así).

Entonces, ¿dónde está el "control de calidad" y la garantía de compilación en una confirmación que esperaría un usuario de subversion? Se desplaza a otras acciones en git. Todavía quiere sacar un estado funcional del programa en un repositorio público. Por lo tanto, asegúrese de que las pruebas sean exitosas y que el programa funcione antes de enviar sus cambios.

Además, intente utilizar ramas al máximo. Cuando cometas muchos cambios pequeños, terminarás con un historial de versiones bastante grande. Si trabaja en sucursales, puede clasificar esas confirmaciones granulares por el nombre de la sucursal y luego fusionarlas nuevamente (la opción --no-fftambién preservará que estas características vivieran en una rama única).

Es decir, puede mantener el hábito de fusionarse solo con la masterrama, si la rama está en buen estado. También puede usar etiquetas para rastrear hitos y lanzamientos.

Ahora, para volver a la puesta en escena: una vez que confirme algunas líneas por confirmación, realizará una etapa directamente antes de la confirmación. (Al menos así es como lo hago).

Creo que te lo estás tomando demasiado en serio. La puesta en escena es solo seleccionar las cosas que desea incluir en la próxima confirmación. Rara vez es importante cuándo o cómo se realiza la puesta en escena; y si tiene muchos cambios por etapas y por etapas en un momento dado, probablemente necesite revisar su proceso de desarrollo.

En un proyecto (post first commit), ¿cuándo es el momento adecuado para organizar los archivos fuente? Justo antes de comprometerse? ¿Justo después de agregar / eliminar o modificar?

Por lo general, lo hago justo antes de comprometerme (a menos que note algún error tipográfico, por lo que tengo que hacer una corrección de último momento y organizarlo también). El proceso es el siguiente: editar, ejecutar pruebas, etapa, confirmación. Si realiza la etapa antes de la prueba, es probable que las pruebas fallen y usted tendrá que hacer cambios y organizarlos también, entonces, ¿por qué no dejarlo hasta el momento de la confirmación?

Si los archivos se organizan a mitad de camino entre dos confirmaciones y luego se modifican, ¿qué sucede con Git? ¿Es necesario preocuparse por los cambios de contenido cuando se declaró y en qué se convirtió desde entonces?

Le mostrará la diferencia entre el estado actual del repositorio y (último compromiso + cambios por etapas). Cuando realice algunos de los nuevos cambios, solo volverá a calcular el estado (último compromiso + cambios por etapas).

Si creo un nuevo archivo, lo organizo y luego quiero eliminarlo, ¿por qué Git me pide que use el indicador "-f" y un simple "git -rm file.ext" no funcionará?

Ahora estoy adivinando aquí, pero probablemente sea porque la información preparada puede ser importante (de lo contrario no la organizarías), pero aún no está bajo el control de la versión (como un archivo que puedes eliminar git -rm). Así que gitquiere asegurarse de saber lo que está haciendo.