Skip to content

Latest commit

 

History

History
88 lines (66 loc) · 6.03 KB

flujo_trabajo_local.md

File metadata and controls

88 lines (66 loc) · 6.03 KB
Raw

Flujo de trabajo local.

Los archivos en un repositorio local Git pasan por 3 fases diferentes:

  1. Working Directory (Directorio de Trabajo).
  2. Staging Área (Área de Preparación o Index).
  3. Git Directory (Directorio Git o HEAD).

La siguiente figura muestra el esquema de flujo de trabajo local de Git:

Fase 1: Working Directory.

En esta fase podemos hacer cualquier cambio en los archivos sin afectar nuestro repositorio (Git Directory). En cuanto modificamos algo en nuestro código, éste tendrá status de modificado. Si ejecutamos el comando git status nos mostrará qué archivos han sido modificados (creados o eliminados).

Una vez que hemos hecho los cambios necesarios, pasamos nuestros archivos al Staging Area (Index) con el comando git add [archivos]. Si existen más archivos modificados que queramos pasar podemos listarlos con git add archivo1.py archivo2.py ..., o también con el comando git add . agregamos todos los archivos modificados del Working Directory al Staging Area.

Cuando se pasan los archivos del Working Directory al Staging Area, se cambia el estado del código de modificado a preparado. Para deshacer los cambios de un archivo en el Working Directory debe usarse el comando git checkout -- [archivo]. Los archivos que estén en el Staging Area no serán modificados. Para deshacer todos los cambios en el Working Directory por un commit en particular, debemos usar el comando git checkout [commit_id] [archivos]. El id_commit podemos obtenerlo con el comando git log --oneline.

Fase 2: Staging Area (Index).

Para pasar nuestro código del Staging Area al Git Directory lo hacemos con el comando git commit -m "[descripción del commit]". Hay distintas modalidades para el comando git commitque pueden leerse aquí. Cuando hacemos el commit el código pasa del estado preparado a confirmado. Para sacar un archivo del Staging Área al Working Directory debe ejecutarse git reset HEAD [archivo]. Para devolver todos los cambios del Staging Area al Working Directory debemos ejecutar git reset --hard. En ambos casos el Working Directory no se alterará

Fase 3: Git Directory (HEAD).

Una vez que el código esta confirmado ya está listo para actualizarse en un servidor remoto de Git (GitHub, GitLab, Bitbucket, etc.) como veremos más adelante.

Ignorar archivos.

A veces será deseable que Git no añada algunos archivos o directorios al Working Directory, o que simplemente estos archivos o directorios no aparezcan como no rastreados. Este suele ser el caso de archivos generados automáticamente o archivos de backup, etc. En estos casos, puedes crear un archivo llamado .gitignore que liste los archivos o patrones de nombres de archivos para evitar que estos sean tomados en cuenta por Git. Podemos encontrar varios ejemplos del archivo .gitignore aquí.

En general, el flujo de trabajo local básico en Git podríamos resumirlo de la siguiente manera:

  1. Modificamos una serie de archivos en el Working Directory.
  2. Preparamos los archivos añadiéndolos al Staging Area con git add.
  3. Confirmamos los cambios con git commit, pasando así los archivos al Git Directory, creando una copia instantánea y permanente en nuestro directorio de Git.

En algunos casos la Fase 2, pasar los archivos al Staging Area, puede omitirse del flujo de trabajo, de tal manera que podemos pasar los archivos directamente del Working Directory al Git Directory añadiendo la opción -a al comando git commit.

Ejemplos de flujo de trabajo local.

  1. Agrega el archivo del Working Directory al Staging Area y luego al Git Directory (ruta completa):
$ git add archivo1.py
$ git commit -m "Corrección de error."
  1. Agrega los archivos del Working Directory al Staging Area y luego al Git Directory (ruta completa):
$ git add archivo1.py archivo2.py archivo3.py
$ git commit -m "Agregando nueva función."
  1. Agrega todos los cambios del Working Directory al Staging Area y luego al Git Directory (ruta completa):
$ git add .
$ git commit -m "Se refactorizó las clases no asociadas."
  1. Agrega todos los cambios del Working Directory directamente al Git Directory (se omite la Fase 2, pero ruta completa):
$ git commit -am "Cambio de formatos."
  1. Agrega archivo1.py y archivo2.py al Stanging Area, luego saca el archivo1.py para finalmente pasar solo el archivo2.py al Git Directory con el commit (ruta incompleta):
$ git add archivo1.py archivo2.py
$ git reset HEAD archivo1.py
$ git commit -m "Corrección del error en el archivo2.py"
  1. Igual que el ejemplo anterior, luego del commit modifica el archivo2.py, se arrepiente de los cambios y lo restituye con la versión del Stanging Area:
$ git add archivo1.py archivo2.py
$ git reset HEAD archivo1.py
$ git commit -m "Corrección del error en el archivo2.py"
# luego modifica el archivo2.py en el *Working Directory*
$ git checkout -- archivo2.py

Como podemos notar, en el flujo de trabajo local básico solo manejamos 4 comandos:

  1. git add [archivos|.] para pasar los cambios del Working Directory al Staging Area.
  2. git commit [-a|-m|"mensaje"] para pasar los cambios del Staging Area al Git Directory.
  3. git reset [HEAD archivo |--hard] para sacar los archivos del Staging Area sin cambiar el Working Directory.
  4. git checkout [--|commit_id|archivo] para deshacer y pasar los cambios del Staging Area (-- archivo) o del Git Directory (commit_id) al Working Directory.

[IR AL ÍNDICE]