Cuando hablamos de terminal nos referimos a un software o programa contenedor que ejecuta un shell. Hace décadas, este era un dispositivo físico que consistía en poco más que un monitor y un teclado. Pero, ¿qué es un shell? Es la interfaz de línea de comandos con la que vamos a interactuar, se encarga de procesar datos y devolver resultados.

Entonces, una terminal es una interfaz que nos sirve para comunicarnos con una computadora, un teclado para entrada de datos y una pantalla para mostrar únicamente caracteres alfanuméricos (sin gráficos).

Y cuando hablamos de consola, ¿a qué nos referimos? Una consola es un tipo especial de terminal. Para empezar a escribir en la consola es necesario hacerlo a través de líneas de comandos, es decir, una instrucción u orden que nosotros (usuarios) le proporcionamos a un sistema informático. Es una instrucción específica dada a una aplicación informática para realizar algún tipo de tarea o función. La línea de órdenes permiten a los usuarios dar instrucciones por medio de textos sencillos como mostrar archivos, crear archivos, mostrar datos, llamar procesos, entre otros.

Ahora bien, cada sistema operativo incorpora un determinado número de comandos básicos, que permiten ejecutar las tareas más simples con órdenes directas. Esos comandos son propios y generalmente varían según el sistema operativo.

Veamos en mayor profundidad estos conceptos y los diversos comandos que podemos utilizar. 

Vamos a aprender una herramienta que nos acompañará a lo largo de la cursada: Git.

Es muy útil para compartir proyectos con distintas personas, tener varias versiones de un mismo proyecto y poder guardar proyectos en la nube. Es por esto que es una de las herramientas más requeridas por el mercado a la hora de trabajar con control de versiones y de forma colaborativa.

Como muchas de las herramientas que veremos a lo largo de la cursada, Git requiere de práctica y tiene muchos accesorios que agregan funcionalidades, pero en esta clase nos centraremos en sus cuestiones principales.

Palabras claves

A modo de resumen, repasemos las palabras claves de este video:

• Repositorio local: es el que tiene todos los archivos (que hayas guardado en él) en nuestra computadora.

• commits: son los paquetes que nos van a permitir ir haciendo un seguimiento de los cambios que vamos realizando, dado que cada uno de ellos tiene una timestamp, o fecha de creación, y un autor.

Los commits van a ser nuestro historial de cambios que se fueron haciendo en el proyecto.

Comandos paso a paso

Vamos a ver paso a paso lo que necesitamos hacer para crear nuestro primer repositorio local.

Antes de empezar a guardar nuestro código, necesitamos hacer dos cosas fundamentales en la terminal: identificarnos y crear el repositorio.

1. Inicialización (git init): Una vez que nos presentamos, vamos a tomar una carpeta común y corriente de nuestra computadora y le daremos "superpoderes". Al inicializarla, Git empezará a rastrear todo lo que ocurra allí dentro. 

2. Configuración de Usuario (git config): Git es un sistema de trabajo colaborativo. Por lo tanto, necesita saber exactamente quién está haciendo cada cambio. Si no configuramos nuestro nombre y correo electrónico ahora, Git no nos dejará guardar nuestro progreso más adelante.

¿Qué acaba de pasar? ¡El cerebro oculto de Git!

Como pudiste notar en la imagen superior, ejecutar esos comandos generó un cambio invisible a simple vista.

• Tus datos quedaron guardados: Al usar el parámetro --global, le dijiste a tu computadora que use ese nombre y correo para todos los proyectos de Git que inicies en esa máquina. (¡Recuerda el Pro-Tip anterior si estás en la facultad!).

• Nació la carpeta .git: El comando git init creó una carpeta oculta dentro de tu proyecto. Ese es el cerebro de tu repositorio. Allí es donde Git guarda el historial, las versiones y los viajes en el tiempo.

💡 Un salvavidas para tus primeros días: Si alguna vez te equivocas tanto practicando que sientes que rompiste todo el repositorio local, ¡no entres en pánico! Simplemente activa la vista de "elementos ocultos" en tu Windows, borra esa carpeta .git y tu proyecto volverá a ser una carpeta normal. Luego, puedes volver a hacer git init y empezar desde cero.

Comandos

Estos son los comandos que vimos en el video:

Cada vez que hacemos un git commit -m "mensaje" , estamos guardando una foto de nuestro proyecto en el tiempo. Para que ese historial sea útil para nosotros y para nuestro equipo, el mensaje debe ser claro y descriptivo.

Por ahora, enfócate en seguir estas dos reglas de oro:

1. Sé específico: Evita mensajes como "cambios", "actualización" o "listo". Explica qué hace el commit. (Ejemplo: "Agrega el botón de inicio de sesión en el menú principal").

2. Usa el modo imperativo: Imagina que el mensaje completa la frase "Si aplico este commit, el repositorio va a...". Por eso, es mejor escribir "Agrega título" en lugar de "Agregué título" o "Agregando título".

Nota: Más adelante aprenderemos un estándar profesional que utiliza la industria para estructurar estos mensajes de forma aún más precisa.

Este diagrama representa el ciclo de vida básico de un archivo en Git, mostrando cómo pasa por distintos estados mediante comandos específicos:

• Untracked (Sin seguimiento): Archivos nuevos en tu proyecto que Git aún no conoce.

  • Transición: Usamos git add para agregarlos al seguimiento (pasan a Tracked).

• Tracked (En seguimiento): Git ya conoce el archivo y está vigilando su historial.

  • Transición: Si queremos dejar de seguirlo, usamos git rm (vuelve a Untracked).

• Modificado: Hemos editado un archivo que ya estaba en seguimiento. Git reconoce que hay cambios nuevos.

  • Transición: Preparamos el archivo para guardarlo (pasa a Stage area).

• Stage area (Listo para commit): Los cambios están en una "zona de preparación", listos para ser confirmados en el historial.

  • Transición: Usamos git commit -m "mensaje" para guardar la versión de forma permanente. El archivo vuelve al estado Tracked, listo para futuras modificaciones.

Palabras clave

A modo de resumen, repasamos las palabras y conceptos clave del video sobre GitHub:

• GitHub es un lugar en la nube.

• Repositorio es el lugar en donde se irán almacenando los archivos de nuestro proyecto y a través del cual podremos hacer seguimiento de los mismos.

• Repositorios remotos: viven en la nube, es decir, en GitHub.

• Repositorios locales: viven en nuestra computadora.

Comandos para vincular tu repositorio local con GitHub

Una vez que creaste tu repositorio vacío en GitHub, copia la URL que te proporciona la plataforma y utiliza los siguientes comandos en tu terminal para subir tu código por primera vez:

1. Vinculamos nuestro repositorio local con el remoto en GitHub (reemplaza la URL por la tuya):

git remote add origin https://github.com/tu-usuario/nombre-del-repo.git

2. Nos aseguramos de que nuestra rama principal se llame main:

git branch -M main

3. Subimos nuestros commits a GitHub y vinculamos la rama local con la remota:

git push -u origin main

(Nota: El parámetro -u solo es necesario la primera vez. Para los siguientes envíos, bastará con escribir git push).

A partir de agosto de 2021, GitHub eliminó el soporte para autenticarse con la contraseña de tu cuenta desde la terminal. Si intentas hacer git push y escribes tu contraseña normal, te dará un error de autenticación.

En su lugar, debes usar un Personal Access Token (PAT). Piensa en el Token como una contraseña especial y segura generada exclusivamente para que la terminal se comunique con GitHub.

Cómo generar tu Token en 5 pasos:

1. Inicia sesión en GitHub desde tu navegador.

2. Haz clic en tu foto de perfil (arriba a la derecha) y ve a Settings (Configuración).

3. En el menú lateral izquierdo, baja hasta el final y haz clic en Developer settings (Ajustes de desarrollador).

4. Haz clic en Personal access tokens y selecciona Tokens (classic).

5. Haz clic en el botón Generate new token (classic).

• En Note, ponle un nombre que identifique la máquina (ej: "Token Notebook Personal" o "Token PC Lab 3").

• En Expiration, ¡presta mucha atención a dónde estás sentado!:

  • 💻 Si estás en TU computadora personal: Puedes elegir "90 days" o "No expiration" para que te dure toda la cursada.

  • 🏫 Si estás en una computadora compartida de la facultad: Elige "7 days". Además, por tu seguridad, si sabes que vas a cambiar de máquina la próxima clase, antes de irte debes volver a esta pantalla en GitHub y hacer clic en el botón "Delete" (Revocar) al lado de tu token para invalidarlo y que nadie más pueda subir código a tu nombre.

6. Baja al final y haz clic en Generate token.

🚨 ¡COPIA ESE CÓDIGO AHORA! GitHub solo te mostrará este Token una sola vez. Cuando la terminal te pida tu "Password" al hacer un git push, en lugar de tu contraseña normal, deberás pegar este Token. (Nota: en muchas terminales, al pegar el token no se verá que escribes nada por seguridad, solo presiona Enter).

En los laboratorios compartidos, es muy común que Windows recuerde la cuenta de GitHub del alumno que usó la PC antes que vos. Si no borras sus credenciales, ¡tus trabajos prácticos se subirán a su nombre!

¿Cuál uso y cuándo?

Para que nunca más te confundas entre fetch y pull, piensa en esta analogía:

Imagina que estás escribiendo un libro con un amigo. El "repositorio remoto" (GitHub) es el borrador final que está en la oficina de la editorial.

• git clone (Clonar): Es tu primer día. Vas a la editorial, pides una copia completa de todo el libro hasta ahora, y te la llevas a tu casa para empezar a trabajar. (Solo se hace una vez por proyecto).

• git fetch (Consultar/Traer): Llamas a la editorial y preguntas: "¿Mi amigo escribió páginas nuevas hoy?". Te dicen que sí y te envían una copia de esas páginas nuevas para que las mires. Ojo: Estas páginas nuevas no se mezclan con lo que tú estás escribiendo en tu escritorio. Solo las tienes ahí para revisarlas. Es una operación segura.

• git pull (Tirar/Extraer y Fusionar): Llamas a la editorial, pides las páginas nuevas de tu amigo, y automáticamente las engrapas en medio de las hojas que tú estabas escribiendo.

⚠️ La Regla de Oro antes de hacer Push:

Si estás trabajando en equipo (o usando la misma rama desde dos computadoras distintas), es muy probable que GitHub rechace tu git push lanzando un error.

Esto sucede porque GitHub detecta que hay cambios en la nube que tú aún no tienes en tu computadora. La solución siempre es:

1. Hacer un git pull primero (para traer lo nuevo y mezclarlo con lo tuyo).

2. Resolver conflictos (si los hay).

3. Ahora sí, hacer tu git push.

¿Qué pasa si te das cuenta de que el último commit que hiciste tiene un error garrafal que rompe todo tu portafolio? En un procesador de texto como Word, simplemente presionarías Ctrl + Z. En el mundo del código, viajar al pasado requiere un poco más de precisión.

Git registra cada commit como una fotografía inalterable del proyecto. Pero, ¿qué pasa si queremos ver una fotografía vieja? ¿O qué pasa si queremos fingir que las últimas tres fotografías nunca existieron?

En este video, exploraremos la "Caja de Herramientas de Emergencia" de Git. Aprenderemos cómo navegar hacia el pasado para inspeccionar versiones antiguas de nuestro código, y descubriremos las diferencias críticas entre deshacer un error de manera segura y reescribir la historia del proyecto de forma destructiva.

¿Cómo le decimos a Git qué cosas NO debe versionar?

A medida que trabajes en tus proyectos, tu editor de código, tu sistema operativo o las herramientas que uses (como Node.js o Python) generarán automáticamente un montón de archivos que no necesitas y no deberías subir a GitHub.

Estamos hablando de:

• Archivos temporales o cachés.

• Carpetas gigantes con dependencias (como node_modules).

• Información sensible y confidencial: Contraseñas, claves de bases de datos o tokens de APIs (archivos .env).

Si accidentalmente subes un archivo con una contraseña a un repositorio público, cualquiera en internet podrá verla. Para evitar esto, existe un archivo mágico llamado .gitignore.

En el siguiente video, descubriremos cómo configurarlo para mantener nuestro repositorio limpio y seguro:

• ¿Qué es? Es un archivo de texto oculto (el punto inicial indica que está oculto) que se coloca en la raíz de tu proyecto. Cada línea dentro de él es un patrón o nombre de archivo que Git ignorará por completo.

• ¿Cómo se usa? Simplemente abres el archivo y escribes lo que quieres ignorar:

  • Ignorar un archivo específico: .env

  • Ignorar toda una carpeta: node_modules/

  • Ignorar todos los archivos de un tipo usando asteriscos (comodines): *.log (Ignorará cualquier archivo que termine en .log).

⚠️ ¡IMPORTANTE! El error más común al usar .gitignore

El video menciona un detalle fundamental: el .gitignore solo funciona para archivos que Git no esté rastreando todavía.

Si por error hiciste un commit de un archivo (por ejemplo, mis_contraseñas.txt) y después lo agregas al .gitignore, ¡Git lo seguirá rastreando y subiendo a GitHub!

💡 Pro-Tip: 

No tienes que inventar el .gitignore desde cero para cada proyecto. Existen generadores automáticos como gitignore.io (ahora parte de Toptal) donde simplemente escribes qué tecnologías usas (ej. Windows, macOS, Node, VisualStudioCode) y te genera el archivo perfecto con todo lo que debes ignorar.

Git Immersión en Español - Jim Weirich, trl.: Espartaco Palma

Git. La guía simple - Roger Dudler, trl.: Luis Barragan, trl.: Adrian Matellanes (HTML)

Gitmagic - Ben Lynn, trl.: Rodrigo Toledo, trl.: Ariset Llerena Tapia (HTML, PDF)

Pro Git - Scott Chacon, Ben Straub, trl.: Andres Mancera, trl.: Antonino Ingargiola, et al. (HTML, PDF, EPUB)

Taller de git - Adrián López - Héctor Romero - Javier de Santiago - José Márquez - Sergio Gómez - Alba Palomino

El archivo README.md es una parte importante de la documentación de un proyecto de software y puede ayudar a los usuarios y desarrolladores a comprender rápidamente cómo utilizar el proyecto. Además, los servicios de alojamiento de repositorios de código fuente, como GitHub, GitLab y Bitbucket, suelen mostrar el contenido del archivo README.md en la página de inicio del proyecto, lo que lo convierte en una herramienta útil para promocionar y presentar el proyecto a otros usuarios y desarrolladores.