Operaciones básicas en un repositorio

Creación

Para crear un repositorio debemos usar el comando git init dentro del directorio que va a contener o ya contiene los archivos del código fuente del proyecto. Es decir, no importa si aún no hay ningún archivo o si ya existe un proyecto avanzado con muchos archivos, de cualquier forma, podemos crear un nuevo repositorio para comenzar a trackear los archivos con Git.

Como dijimos, Git es una herramienta de línea de comandos y para usarlo, en Windows, debemos usar alguna aplicación que proporcione una terminal de línea de comandos.

Como lo hicimos en la configuración inicial, podemos usar Git Bash, que es la opción recomendada. Pero también es posible utilizar otras aplicaciones de línea de comandos de Windows, como CMD o PowerShell, y, como veremos más adelante, también podemos usar aplicaciones con GUI, como Visual Studio Code.

Para facilitar su uso, Git Bash incluye la funcionalidad para abrirse dentro de un directorio desde el Explorador de Windows. Por lo tanto, para crear un nuevo repositorio, debemos navegar hasta el directorio del proyecto, hacer clic derecho y elegir la opción “Git Bash Here”.

Alternativamente, podemos abrir Git Bash desde el menú Inicio, como antes, y luego navegar hasta el directorio deseado, desde la línea de comandos de bash.

git bash here

Aquí es donde vamos a ejecutar el comando.

1
git init

Al ejecutar git init, se creará automáticamente la carpeta oculta .git, y Git nos informará que se inicializó el repositorio vacío en ella.

git init

En la imagen de ejemplo, Windows está configurado para mostrar los elementos ocultos, por eso se puede ver la carpeta oculta .git. Si no tenemos esta configuración activada en Windows, no vamos a poder ver la carpeta (pero estará allí).

Por otro lado, podemos ver que Git Bash nos muestra, antes del prompt, y entre paréntesis, en qué branch nos encontramos. En este caso, como no creamos una branch manualmente, automáticamente se utiliza el nombre main para la branch inicial.

Estados de los archivos de un proyecto

Los archivos de un proyecto pueden encontrarse en distintos estados, dependiendo de: si ya están siendo trackeados por Git o no, si se modificaron o si se agregaron al proyecto.

Estos estados se describen a continuación.

Un archivo que está en el directorio de trabajo, pero no se está trackeando va a tener, para Git, un estado de Untracked (sin seguir). Todos los archivos de un repositorio comienzan como untracked. Para comenzar a trackear un archivo debemos usar el comando git add, el cual marcará al archivo y lo pondrá en el estado Staged, que veremos a continuación.
Un archivo que sí se está trackeando puede estar en tres estados posibles.
- Modified (modificado): se editó desde el último commit, pero no se marcaron ni guardaron los cambios. Mientras trabajamos en un archivo, va a tener este estado.
- Staged (preparado): se marcaron los archivos y sus cambios se guardan temporalmente en el área de staging (preparación) para posteriormente ser guardados permanentemente. Podemos marcar archivos en estado untracked, como dijimos antes, y archivos ya trackeados, pero que hayan sido modificados. Siempre podemos volver atrás desde este punto (“desmarcar” los archivos).
- Committed (confirmado o guardado): los cambios que estaban en el área de staging (el snapshot) se guardaron permanentemente en el repositorio.

`.gitignore`

Git implementa una funcionalidad para ignorar ciertos archivos o directorios que el desarrollador necesita tener en el directorio de trabajo, pero no en el repositorio.

Esta funcionalidad se implementa mediante un archivo llamado .gitignore. Este archivo simplemente contiene descripciones glob que igualan a nombres o extensiones de archivos y carpetas, lo que permite a Git identificarlos e ignorarlos al escanear un directorio.

Por ejemplo, si en nuestro directorio de trabajo tenemos un directorio donde se encuentra un entorno virtual, o si tenemos la carpeta __pycache__, o directorios creados al realizar un build, etc. Estos archivos y/o directorios deben ser ignorados por Git ya que son generados automáticamente por el entorno de trabajo o al ejecutar o compilar código, o son configuraciones del IDE y no tienen nada que ver con el código fuente en sí.

Un archivo .gitignore puede verse de la siguiente forma:

1
# .gitignore
2
__pycache__
3
build
4
*.pdf
5
*.xlsx

En este ejemplo, en primer lugar, vemos un comentario que este comienza con el caracter #. Esta línea no será tenida en cuenta por Git.

Luego, se listan los directorios y los archivos que serán ignorados por Git, __pycache__ y build y archivos con extensiones pdf y xlsx. Estos últimos (con el carácter comodín *) indican que se ignorarán cualesquiera que sean sus nombres.

Finalmente, podemos hablar de un último estado, pero no de un archivo específicamente, sino de una branch. Si estamos trabajando con repositorios remotos en plataformas como GitHub, una branch puede tener su copia en la nube. En tal caso, nuestra branch local puede estar al dia (los mismos commits), puede estar adelantada (uno o más commits posteriores), atrasada (uno o más commits por detrás) o puede estar adelantada y atrasada a la vez, ya que otras personas pueden haber avanzado en la branch remota y nosotros en la local.

Ver el estado actual

Para saber en qué estado están los archivos de un repositorio debemos ejecutar el comando git status. Este comando nos indicará si existen cambios no guardados en nuestro directorio de trabajo (entre otras cosas).

git status

En este caso, en nuestro nuevo repositorio vacío, no hay nada que guardar.

Si creamos un nuevo archivo y volvemos a ejecutar git status, este figurará como untracked.

Agregar cambios al área de staging

Para comenzar a trackear el archivo creado, debemos usar el comando git add <archivo>. Este comando no mostrará ninguna salida si se ejecuta sin errores.

Una vez que ejecutamos git add el archivo estará en el área de staging, o sea en el estado staged. Lo podemos ver ejecutando nuevamente git status.

El procedimiento es el mismo si el archivo ya estaba siendo trackeado y lo modificamos.

Guardar cambios permanentemente

Finalmente, para guardar definitivamente este cambio en el repositorio, debemos ejecutar git commit.

Por ejemplo:

1
git commit -m "Agregado entry point, main.py."

De esta forma el comentario quedará ligado al commit y tendrá un detalle de qué cambios se agregaron en esa nueva versión.

Una vez ejecutado el commit, veremos que no hay cambios en el directorio de trabajo ni en el área de staging. El archivo ya está en el estado committed.

Flujo de trabajo con Git

Habiendo visto lo anterior, podemos establecer cómo es el flujo básico de trabajo con Git.

Se crea el repositorio local.
Se crean, modifican o eliminan los archivos en el directorio de trabajo.
Se eligen y marcan cuáles archivos se quiere agregar al área de staging para ser agregados al próximo commit.
Se guardan los cambios marcados al repositorio de manera permanente, efectuando un commit.
(opcional) Si estamos trabajando con un repositorio remoto, en este punto (después de un commit), podemos sincronizar los cambios locales a GitHub (o la plataforma que estemos usando). Para esto, el repositorio remoto, llamado remote por Git, debe existir y estar configurado previamente en nuestro repositorio local. Veremos más sobre repositorios remotos próximamente.
Volver al paso 2.

flujo git

Secciones de un proyecto trackeado por Git

Ya vimos los estados que pueden tener los archivos, ahora vamos a ver cómo se organiza un repositorio desde el punto de vista de Git. Las secciones, como veremos, están directamente relacionadas con los estados. Conocer esto nos ayudará a entender, conceptualmente, cómo trabaja Git.

Git diferencia entre las siguientes secciones:

Directorio de trabajo o working tree. Es el área de trabajo donde están disponibles los archivos de nuestro proyecto y donde los podemos visualizar y editar.
Área de staging o preparación. Es un área especial dentro del directorio oculto .git donde se guarda la información de los archivos que han sido marcados para guardar sus cambios.
Repositorio. Es la sección del directorio oculto .git donde se guardan permanentemente todos los snapshots de los distintos cambios y estados del proyecto. Es el repositorio propiamente dicho y contiene todo lo necesario para recuperar el proyecto si hace falta. Su contenido es lo que se sincroniza con un repositorio remoto.
Repositorio remoto. Es el repositorio ubicado en alguna plataforma online, como GitHub, el cual se usa como repositorio central para proyectos con múltiples colaboradores. En un flujo de trabajo distribuido, cada integrante del equipo de desarrollo debe sincronizar su repositorio local con este repositorio remoto, subiendo cambios propios y descargando cambios que hayan hecho los demás.

Areas de git