¿Por qué querría escenario antes de comprometerme en Git?

Question

Soy nuevo en el control de versiones y entiendo que "comprometer" es esencialmente crear una copia de seguridad al actualizar la nueva versión "actual" de lo que está trabajando.

Lo que no entiendo es para qué es una puesta en escena desde una perspectiva práctica. ¿Es escenificar algo que existe sólo por nombre o sirve para un propósito? Cuando te comprometes, va a cometer todo de todos modos, ¿verdad?

Editar: Creo que puedo estar confundiendo la terminología. ¿Es un archivo 'escalonado' lo mismo que un archivo 'rastreado'?

Answer 1

Cuando confirma, solo va a confirmar los cambios en el índice (los archivos "en etapas"). Hay muchos usos para esto, pero el más obvio es dividir tus cambios de trabajo en piezas más pequeñas e independientes. Tal vez corrigió un error mientras implementaba una función. Puede git add solo ese archivo (o git add -p para agregar solo parte de un archivo) y luego confirmar ese error antes de confirmar todo lo demás. Si está usando git commit -a, solo está forzando un add de todo antes de la confirmación. No use -a si desea aprovechar los archivos intermedios.

También puede tratar los archivos escalonados como una copia de trabajo intermedia con el --cached para muchos comandos. Por ejemplo, git diff --cached le mostrará cómo el escenario difiere de HEAD para que pueda ver lo que está a punto de comprometer sin mezclar en sus otros cambios de trabajo.

Answer 2

• El área de ensayo le da el control para hacer un compromiso más pequeño. Simplemente realice un cambio lógico en el código, agregue los archivos modificados al área de preparación y, finalmente, si los cambios son incorrectos, realice la compilación de la confirmación anterior o confirme los cambios. Ofrece la flexibilidad de dividir la tarea en tareas más pequeñas y comprometerse cambios. Con el área de preparación es más fácil concentrarse en tareas pequeñas.
• También le ofrece la oportunidad de descansar y olvidarse de la cantidad de trabajo que ha realizado antes de tomarse un descanso. Supongamos que necesita cambiar tres archivos para hacer un cambio lógico y ha cambiado el primer archivo y necesita un descanso prolongado hasta que comience a hacer los otros cambios. En este momento no puede comprometerse y desea rastrear qué archivos ha terminado para que, después de volver, no tenga que intentar recordar cuánto trabajo se ha realizado. Así que agrega el archivo al área de ensayo y guardará tu trabajo. Cuando vuelvas, haz "git diff --staged" y comprueba qué archivos cambiaste y dónde y comienza a hacer otros cambios.

Answer 3

El área de preparación nos ayuda a diseñar los compromisos con mayor flexibilidad. Al crear, me refiero a dividir las confirmaciones en unidades lógicas. Esto es muy importante si quieres un software que se pueda mantener. La manera más obvia de lograr esto:

Puede trabajar en varias características/errores en un solo directorio de trabajo y aún generar confirmaciones significativas. Tener un único directorio de trabajo que contenga todo nuestro trabajo activo también es muy conveniente. (Esto se puede hacer sin un área de transición, solo mientras los cambios nunca se superpongan a un archivo. Y también tiene la responsabilidad adicional de rastrear manualmente si se superponen)

Puede encontrar más ejemplos aquí: Uses of Index

Y la mejor parte es que las ventajas no se detienen en esta lista de flujos de trabajo. Si surge un flujo de trabajo único, puede estar casi seguro de que el área de preparación le ayudará.

Answer 4

Es más fácil entender el uso de los comandos git add y commit si imagina que se está manteniendo un archivo de registro en su repositorio en Github. archivo de registro de un proyecto típico para mí puede ser:

---------------- Day 1 -------------------- 
Message: Completed Task A 
Index of files changed: File1, File2 

Message: Completed Task B 
Index of files changed: File2, File3 
------------------------------------------- 

---------------- Day 2 -------------------- 
Message: Corrected typos 
Index of files changed: File3, File1 
------------------------------------------- 
... 
... 
...and so on 

Por lo general comienzan el día con una solicitud git pull y terminar con una petición git push. Entonces, todo lo que está dentro del registro de un día corresponde a lo que ocurre entre ellos. Durante cada día, hay una o más tareas lógicas que completa, que requieren el cambio de algunos archivos. Los archivos editados durante esa tarea se enumeran en un índice.

Cada una de estas subtareas (Tarea A y Tarea B aquí) son confirmaciones individuales. El comando git add agrega archivos a la lista 'Índice de archivos modificados'. Este proceso también se denomina estadificación. El comando git commit registra/finaliza los cambios y la lista de índice correspondiente junto con un mensaje personalizado.

Recuerde que solo está cambiando la copia local de su repositorio y no la de Github. Después de esto, solo cuando haces un 'git push', todos estos cambios registrados, junto con tus archivos de índice para cada confirmación, se registran en el repositorio principal (en Github).

A modo de ejemplo, para obtener la segunda entrada en ese archivo de registro imaginario, lo habría hecho:

git pull 
# Make changes to these files 
git add File3 File4 
# Verify changes, run tests etc.. 
git commit -m 'Corrected typos' 
git push 

En pocas palabras, git add y git commit le permite desglosar un cambio en el repositorio principal en sistemática subcambios lógicos. Como otras respuestas y comentarios han señalado, por supuesto que hay muchos más usos para ellos. Sin embargo, este es uno de los usos más comunes y un principio de conducción detrás de que Git sea un sistema de control de revisiones de varias etapas a diferencia de otros populares como Svn.

Answer 5

Un objetivo práctico de la puesta en escena es la separación lógica de confirmaciones de archivos.

Como la etapa le permite continuar realizando modificaciones en los archivos/directorio de trabajo y realizar confirmaciones en partes cuando crea que las cosas están listas, puede usar etapas separadas para las ediciones lógicamente no relacionadas.

Supongamos que tiene 4 archivos fileA.html, fileB.html, fileC.html y fileD.html. Realiza cambios en los 4 archivos y está listo para confirmar, pero los cambios en fileA.html y fileB.html están relacionados lógicamente (por ejemplo, la misma implementación de característica nueva en ambos archivos) mientras que los cambios en fileC.html y fileD.html son independientes y no guardan relación alguna con los archivos anteriores. Primero puede organizar los archivos fileA.html y fileB.html y confirmarlos.

git add fileA.html 
git add fileB.html 
git commit -m "Implemented new feature XYZ" 

Luego, en el siguiente paso, realiza etapas y confirma los cambios en los dos archivos restantes.

git add fileC.html 
git add fileD.html 
git commit -m "Implemented another feature EFG"