Emptiness Matching |
Heavy is the Crowd |
Emptiness Matching (Neuro-Sama) |
Profesorcito © 2025
Chester Bennington 🕊️ (2017)
En este curso de Programación Orientada a Objetos (POO) 🔥 con C++ 💻, exploraremos conceptos clave como clases, objetos y herencia 🚀. Aprenderás cómo aplicar estos principios de forma efectiva para crear proyectos potentes. Pero antes de sumergirnos en la programación, es esencial que dominemos una herramienta fundamental para gestionar el código de manera eficiente: Git 🧑💻.
- Introducción a Git
- Principales características de Git
- Instalación de Git
- Configuración inicial de Git
- Comandos básicos
- Manejo de Conflictos en Git
- Moviéndonos en el Historial de Git
- Prácticas
- Práctica #1 Usando
git init🖥️ - Práctica #2 Usando
git add,git statusygit commit📝 - Práctica #3 Usando
git logygit diff🔍 - Práctica #4 Usando
git branchygit checkout🌿 - Práctica #5 Usando
git merge🔗 - Práctica #6 Usando
git push📤 - Práctica #7 Usando
git pull⬇️ - Práctica #8 Manejo de Conflictos en
git merge⚠️
- Práctica #1 Usando
En este curso aprenderás a utilizar Git, un sistema de control de versiones distribuido (Version Control System, VCS) 🌍, que te permite rastrear cambios en tu código 📝, colaborar con otros desarrolladores 🤝 y gestionar múltiples versiones de tus proyectos 🚀.
Hoy en día, el control de versiones (VCS) es una habilidad imprescindible en el desarrollo de software. Grandes empresas como Google, Facebook, Microsoft, Amazon, Netflix y Apple gestionan gigantescos proyectos con miles de desarrolladores trabajando al mismo tiempo. Git permite coordinar de manera eficiente esos esfuerzos titánicos, garantizando:
- Control de los cambios. 🔒💻
- Ausencia de conflictos entre desarrolladores. 🤝🔧
- La posibilidad de regresar a versiones anteriores. 🔙🛠️"
Desde proyectos individuales hasta gigantescas colaboraciones en equipo, Git es una herramienta indispensable para gestionar el flujo de trabajo y garantizar el éxito de cualquier proyecto.
Note
Es como dicen los bomberos, "¡no hay que pisarse la manguera!" 🚒. Git permite que los desarrolladores colaboren sin interferencias, ya que las ramas independientes organizan y aíslan las tareas de cada uno, permitiendo un flujo de trabajo sin tropiezos.
💡 Hint: ¿Te suena Git? 🤔
¡Seguro lo has escuchado un millón de veces!
No es casualidad que estas herramientas estén por todas partes en el mundo del desarrollo. Si ya tienes algo de experiencia, ¡perfecto! Este curso te ayudará a llevar esas habilidades al siguiente nivel. Y si aún no has tenido la oportunidad de profundizar en ellas, no te preocupes, ¡aquí aprenderás a dominarlas de manera efectiva! 😎
💡 Hint: Git vs GitHub 🤔
Git es como una caja de herramientas 🧰 en tu computadora. Te permite gestionar y controlar tu código, guardar versiones y retroceder cuando algo sale mal. Todo esto ocurre de manera local en tu máquina. 🖥️ GitHub, en cambio, es como un almacén en la nube 🌥️ donde puedes guardar, compartir y colaborar con otros desarrolladores. Es el lugar donde subes tu repositorio Git para trabajar en equipo más fácilmente.
En resumen: Git es para trabajar localmente en tu máquina y GitHub es para compartir tu trabajo en línea. 🌐
En este curso, primero aprenderemos Git para gestionar tu código de manera eficiente, y luego GitHub para compartir y colaborar con otros. 🚀
💡 Hint: ¿Sabías que Git fue creado por Linus Torvalds? 👨💻
Git fue creado por Linus Torvalds, el brillante finlandés 🇫🇮 detrás de Linux 🐧. Aunque mucha gente asocia su nombre con Estados Unidos, Linus nació en Helsinki, Finlandia, en 1969. Así que, la próxima vez que uses Git, recuerda que todo comenzó en el corazón de Escandinavia ❄️.
En 1991, mientras aún estudiaba en la Universidad de Helsinki 🎓, Linus desarrolló Linux como un proyecto personal, con la idea de crear un sistema operativo libre, accesible y flexible. El resto, como sabemos, es historia. Linux ha revolucionado la tecnología, desde servidores hasta dispositivos móviles 📱💻.
Y aquí va un dato curioso: aunque Linus Torvalds y el profesorcito 👨🏫 nunca coincidieron en persona, el profesorcito tuvo la suerte de trabajar en una estancia de investigación en la Universidad de Helsinki 🏫, la misma universidad donde Linus desarrolló Linux. Esto ocurrió en 2002, cuando Linus ya no formaba parte de la universidad. Así que, en cierto modo, el profesorcito caminó por el mismo suelo donde Linus forjó el futuro del software 🚀.
cada vez que uses Git, el legado de Linus Torvalds está detrás de cada línea de código 💻. Y aunque no fue Linus quien me enseñó, fue su visión la que, indirectamente, me inspiró a compartir este conocimiento contigo en este curso. ¡Vamos a por ello! 💪
💡 Hint: ¿Por qué se llama Git? 🤔
El nombre Git fue elegido por Linus Torvalds de manera algo peculiar. En inglés, "git" es una palabra que se usa como una expresión de desdén, algo así como "tonto" o "idiota" 😅. Linus, conocido por su sentido del humor y su actitud irreverente, decidió darle este nombre al sistema de control de versiones para reflejar su carácter desafiante.
En sus propias palabras, Linus Torvalds dijo que Git es “un sistema de control de versiones para personas inteligentes”, y que él mismo eligió ese nombre como una forma de reírse un poco de sí mismo y de los demás desarrolladores. ¡Una elección original y muy Linus! 😎
Por si tienes curiosidad, puedes ver la traducción de "he is git and she is also git" al español en Google Translate.
Git es un sistema de control de versiones descentralizado 🔄 y distribuido 🌍: Cada desarrollador tiene una copia completa del proyecto en su máquina local, sin depender de un servidor central, lo que permite trabajar de manera independiente y sin conexión, garantizando una colaboración eficiente y sin riesgos.
Estas son las características más destacadas de Git:
- 🔄 Descentralizado: No depende de un servidor central.
- 🌍 Distribuido: Cada desarrollador tiene una copia completa del proyecto y su historial de cambios.
- 🤝 Colaborativo: Permite que múltiples desarrolladores trabajen en el mismo proyecto simultáneamente.
- 📜 Histórico: Mantiene un registro detallado de todos los cambios realizados.
- ⚙️ Versátil: Escala perfectamente desde proyectos pequeños hasta desarrollos en empresas multinacionales.
- ⚡ Velocidad: Git es increíblemente rápido, incluso con proyectos grandes.
- 🔓 Open-Source & Gratuito: Git es un software libre y de código abierto, lo que significa que es accesible para todos y continuamente mejorado por la comunidad.
Para instalar Git en tu sistema, sigue las instrucciones específicas para tu sistema operativo:
-
Windows: Descarga el instalador desde git-scm.com y sigue las instrucciones del asistente de instalación.
-
macOS: Puedes instalar Git utilizando Homebrew. Ejecuta el siguiente comando en la terminal:
brew install git
-
Linux: Utiliza el gestor de paquetes de tu distribución. Por ejemplo, en Debian o Ubuntu:
sudo apt-get update sudo apt-get install git
-
Abre tu navegador favorito y dirígete a la página oficial de Git:
👉 https://git-scm.com/downloads -
Una vez en la página, verás una imagen similar a la siguiente:
Note
Al momento de escribir este tutorial, la versión más reciente es la 2.48.1, pero esta puede variar dependiendo de cuándo lo estés realizando.
-
Como puedes observar, el sitio web detectará automáticamente tu sistema operativo (en este caso, Windows).
- Si no lo detecta correctamente, selecciona manualmente el enlace correspondiente a tu sistema operativo.
-
Haz clic en el botón Download for Windows
-
A continuación, haz clic en el enlace Click here to download que aparece en la siguiente ventana:
- Una vez descargado el archivo, ábrelo para iniciar el instalador.
- En la ventana de select components no cambien nada solo da click en next, next:
-
Sigue los pasos del asistente de instalación:
- Presiona Siguiente en cada pantalla.
-
¡Y listo! Git estará instalado en tu computadora. 🎉
- Git Bash es una aplicación que se instala junto con Git. Esta terminal es muy importante porque:
- Te permite ejecutar comandos de Git.
- Emula comandos de Linux, que son muy útiles para trabajar con Git.
Caution
No utilices la terminal predeterminada de Windows (cmd) cuando trabajes con Git, ya que puede causarte problemas y más de un dolor de cabeza durante el curso. Usa siempre Git Bash. ¡Es más confiable y hará tu vida más fácil! 😎🚀
Para comenzar a usar Git Bash, sigue estos pasos:
- Ve al menú de inicio de tu sistema operativo.
- Busca "Git Bash" en la barra de búsqueda.
- Haz clic en el icono de Git Bash para abrirlo.
Así es como debería verse la ventana de Git Bash cuando lo abras:
Para asegurarte de que Git está instalado correctamente, ejecuta el siguiente comando:
git --versionEste comando mostrará la versión de Git instalada. Si ves algo como esto:
git version 2.47.1.windows.2¡Genial! Git está correctamente instalado y listo para usarse. 🎉
💡 Hint: ¿Qué hacer si no te aparece nada? 🤔
Si al ejecutar el comando no ves ninguna respuesta o aparece un error, es posible que Git no esté instalado correctamente o no se haya agregado al PATH de tu sistema. En ese caso, te sugiero revisar la instalación o volver a instalar Git siguiendo los pasos previos. 🔧Recuerde que profesorcito siempre estará allí para brindarle su apoyo y guiarle. ¡No dude en pedir ayuda, estamos en esto juntos! 🙌👨🏫💡
Ahora que Git está listo para usarse, es necesario configurarlo con tu nombre y correo electrónico. Esto solo se hace una vez y es fundamental para que Git pueda asociar tus cambios a tu identidad. Vamos a configurarlo:
-
Escribe este comando en Git Bash para configurar tu nombre:
git config --global user.name "Tu Nombre"Reemplaza
"Tu Nombre"por tu nombre real. -
Configura tu correo electrónico:
git config --global user.email "tu@correo.com" -
Opcional: Configura un editor para que Git utilice
En ciertas ocasiones, Git abrirá un editor de texto para que ingreses información o realices ajustes, como describir cambios o resolver conflictos. De forma predeterminada, utiliza un editor básico (como vim), que puede no ser el más intuitivo. Configurar un editor que conozcas y prefieras mejorará tu experiencia, haciéndola más ágil y consistente.
Por ejemplo, para usar Notepad en Windows, ejecuta:
git config --global core.editor "notepad"Note
Profesorcito te recomienda Notepad, porque le encanta lo sencillo y eficiente. Es perfecto para comenzar, sin complicaciones. Sin embargo, Linus Torvalds, el creador de Git, seguramente preferiría Vim. Vim es un editor muy eficiente para usuarios avanzados, especialmente cuando se trabaja directamente desde la terminal. Es rápido y no necesita un entorno gráfico, lo que lo hace ideal para entornos de desarrollo más técnicos. 💻
💡 Hint: Otros editores que puedes usar con Git
-
Notepad (Windows):
git config --global core.editor "notepad" -
Visual Studio Code:
git config --global core.editor "code --wait" -
Sublime Text:
git config --global core.editor "subl -n -w" -
Atom:
git config --global core.editor "atom --wait" -
Vim:
git config --global core.editor "vim" -
Nano:
git config --global core.editor "nano" -
Emacs:
git config --global core.editor "emacs"
Los editores Vim y Nano vienen preinstalados con Git Bash. Notepad viene preinstalado con Windows. Los demás editores (Visual Studio Code, Sublime Text, Atom, Emacs) necesitarán ser instalados por separado.
- Configura el manejo de finales de línea
Los sistemas operativos manejan los finales de línea de manera diferente, lo que puede generar problemas al trabajar en un proyecto colaborativo. Aquí te explicamos cómo se gestionan los saltos de línea en distintos sistemas:
- Windows utiliza CR+LF (Carriage Return + Line Feed), es decir, dos caracteres especiales:
\r\n. - Linux/macOS solo utiliza LF (Line Feed), representado por
\n.
Note
- CR (Carriage Return): Es un carácter que regresa el cursor al principio de la línea. Su representación es
\r📝. - LF (Line Feed): Es un carácter que mueve el cursor hacia abajo a la siguiente línea. Su representación es
\n↘️ . En Windows, los archivos de texto utilizan CR+LF (\r\n) como final de línea. En cambio, en Linux y sistemas similares (como macOS), únicamente se usa LF (\n) ⚙️.
Imagina que dos desarrolladores están trabajando en el mismo repositorio:
- Desarrollador A está usando Windows.
- Desarrollador B está usando Linux/macOS.
Cuando el Desarrollador A (en Windows) agrega un salto de línea, Git registra dos caracteres (CR+LF), mientras que el Desarrollador B (en Linux/macOS) solo usa un carácter (LF). Este desajuste puede causar conflictos, ya que Git detectará cambios innecesarios en los archivos debido a los diferentes finales de línea.
Para evitar estos problemas, Git incluye la configuración core.autocrlf, que ajusta automáticamente los finales de línea según el sistema operativo que estés usando. Git se encarga de convertir los saltos de línea de manera adecuada al momento de descargar o subir archivos, así no tendrás que preocuparte por los detalles.
- En Windows: Git convertirá los saltos de línea de
LFaCRLFal descargar archivos y deCRLFaLFal subirlos. - En Linux/macOS: Git solo convertirá
CRLFaLFcuando sea necesario, pero no realizará cambios adicionales.
-
Si usas Windows: Configura Git para manejar los finales de línea de manera automática, adaptando los saltos de línea a
CRLFal descargar archivos y convirtiéndolos aLFal subirlos:git config --global core.autocrlf true -
Si usas Linux/macOS: Configura Git para que solo guarde los saltos de línea con
LFy elimine los caracteresCRsi se introducen accidentalmente:git config --global core.autocrlf input
Esta configuración asegura que los archivos se mantengan consistentes sin importar el sistema operativo que estés utilizando, evitando conflictos innecesarios relacionados con los saltos de línea. 🙌
🎩 Tricks: Conviértete en un mago avanzado de Git
¿Quieres dominar Git desde la terminal? 🚀 Vamos a explorar algunos comandos que te harán un experto en configuraciones.
Usa este comando para abrir y editar las configuraciones globales:
git config --global -e👀 ¿Qué pasa aquí? Este comando abre el archivo .gitconfig, que se encuentra en la raíz de tu directorio home (~). Este archivo contiene configuraciones clave como tu nombre de usuario y correo electrónico que configuraste previamente. Puedes editar este archivo directamente y cualquier cambio que realices se reflejará en las configuraciones globales.
Además de editar las configuraciones, también puedes visualizarlas de diferentes maneras:
- Listar las configuraciones globales actuales:
git config --global --list
-
Listar todas las configuraciones actuales:
git config --list
Después de ejecutar estos dos comandos, la ventana se verá de la siguiente manera:
✨ Pro Tip: Investiga más opciones de configuración para personalizar Git a tu gusto. Por ejemplo, puedes definir alias para comandos frecuentes o establecer comportamientos específicos para tus repositorios.
La terminal es tu mejor aliada para entender y personalizar Git. Con práctica, ¡te convertirás en un verdadero maestro de las Git! 🧙♂️✨
Important
En este curso, nos centraremos en aprender Git desde la terminal 🖥️. Esto te permitirá entender a fondo cómo funciona Git, dándote el control total sobre tus proyectos y tu flujo de trabajo 💪. Una vez que te sientas cómodo trabajando en la terminal, puedes explorar herramientas gráficas como GitHub 🌐.
Warning
Es posible que, al aprender Git desde la terminal, te enamores de ella ❤️ y nunca más quieras salir. 😅 La terminal puede ser adictiva, ¡pero no te preocupes, es un amor que vale la pena!
Antes de comenzar con los comandos específicos de Git, es importante conocer algunos comandos básicos de Bash que utilizaremos para movernos por el sistema de archivos y realizar tareas esenciales. Los comandos que veremos incluyen:
ls: Para listar los archivos y directorios.clear: Para limpiar la pantalla de la terminal.pwd: Para conocer tu ubicación actual en el sistema.mkdir: Para crear un nuevo directorio.rmdir: Para eliminar un directorio vacío.cd: Para cambiar de directorio.
Con estos comandos, podrás navegar y organizar tu entorno de trabajo antes de sumergirnos en los comandos de Git. ¡Vamos a empezar! 💻✨
El comando ls se utiliza para listar los archivos y directorios en el directorio actual. Al escribir este comando, verás una lista simple de los archivos y carpetas, pero no mostrará los archivos ocultos (aquellos que comienzan con un punto .). 👀
lsSi quieres ver también los archivos ocultos y obtener más detalles, puedes usar ls -al. Este comando combina dos opciones: -a para mostrar todos los archivos, incluidos los ocultos, y -l para ver una lista detallada con información como permisos, propietario, tamaño y fecha de modificación. 📝
ls -alCon este comando, verás no solo los archivos ocultos, sino también información adicional que te ayudará a entender mejor cómo está organizado tu directorio. 📋
El comando clear se utiliza para limpiar la pantalla de la terminal. Cuando lo ejecutas, elimina todo el texto y la información que se muestra en la ventana, dejándola vacía para que puedas ver mejor lo que haces a continuación. Esto es útil si tienes muchas líneas de salida o si simplemente quieres empezar de nuevo sin distracciones. 🌟
clearUn atajo de teclado que hace lo mismo es Ctrl+L. Si prefieres no escribir el comando, simplemente presiona Ctrl y L al mismo tiempo y la pantalla se limpiará al instante. ¡Es aún más rápido! ⚡
El comando pwd (print working directory) se utiliza para mostrar la ruta completa del directorio actual en el que te encuentras. Esto es útil cuando no sabes en qué carpeta estás trabajando, ya que te da la ruta exacta desde la raíz del sistema. 🗺️
pwdAl ejecutar este comando, verás la ruta completa de tu directorio actual, por ejemplo:
Este comando es una excelente manera de orientarte en tu estructura de carpetas.
El comando mkdir (que significa Make Directory) se utiliza para crear un nuevo directorio o carpeta dentro del sistema de archivos. Este comando es esencial cuando necesitas organizar tus archivos y proyectos en diferentes carpetas.
- Crear una nueva carpeta: Supongamos que quieres crear una carpeta llamada
mirepoen el directorio actual donde te encuentras. Para hacerlo, escribes:
mkdir mirepoEste comando crea la carpeta mirepo en tu ubicación actual, ya sea en tu directorio home, escritorio o cualquier otra carpeta en la que estés trabajando.
- Crear varias carpetas al mismo tiempo: También puedes crear varias carpetas a la vez utilizando un solo comando. Por ejemplo, para crear
proyecto1yproyecto2:
mkdir proyecto1 proyecto2Este comando crea ambas carpetas en el directorio donde te encuentras.
- Crear una carpeta dentro de otra: Si quieres crear una carpeta dentro de otra, puedes hacerlo especificando la ruta. Por ejemplo, para crear una carpeta
documentosdentro demirepo, puedes hacer:
mkdir mirepo/documentosSi mirepo ya existe, mkdir crea documentos dentro de mirepo. Sin embargo, si mirepo no existe, se generará un error, ya que el comando mkdir no creará automáticamente directorios intermedios (sin usar la opción -p).
- Forzar la creación de directorios intermedios con
-p: Si necesitas crear una estructura de directorios completa y algunos de ellos no existen aún, puedes usar la opción-p. Esto permite crear directorios de manera recursiva, es decir, si el directorio principal no existe, también lo creará junto con los subdirectorios que especifiques. Por ejemplo, para crearkoko1/koko2(y asegurarte de que ambos directorios se creen, aunquekoko1no exista):
mkdir -p koko1/koko2Este comando crea koko1 y dentro de él, koko2, sin importar si koko1 ya existe o no.
El comando rmdir se utiliza para eliminar un directorio vacío en el sistema de archivos. Es útil cuando ya no necesitas una carpeta vacía y deseas liberar espacio.
-
Eliminar un directorio vacío: Para eliminar una carpeta llamada
mirepo(que debe estar vacía), simplemente ejecutas:rmdir mirepo
Este comando elimina
mireposolo si está vacío. Si contiene archivos o subdirectorios, recibirás un error comormdir: failed to remove 'mirepo/': Directory not empty -
Eliminar directorios no vacíos con
rm -r:
¡Con mucha precaución! Si deseas eliminar un directorio que no esté vacío, debes usar rm -r. Este comando eliminará el directorio y todo su contenido (archivos y subdirectorios).
Por ejemplo, para eliminar koko1 y todo lo que contiene:
rm -r koko1Caution
Este comando elimina todo el contenido de la carpeta koko1 de manera permanente, ¡sin posibilidad de recuperación fácilmente! Asegúrate de que realmente quieres eliminar todo antes de usarlo.
El comando cd (que significa Change Directory) se utiliza para navegar entre directorios dentro de tu sistema de archivos. Te permite moverte a diferentes carpetas para poder trabajar en ellas.
-
Ubicarte en el directorio correcto:
Supongamos que estás en tu directorio
home(es decir, en la raíz de tu usuario) y quieres moverte a tu escritorio donde vas a crear una nueva carpeta.Para hacerlo, utilizas el comando
cdseguido de la ruta al directorio:cd ~ cd Desktop
Este comando te llevará al directorio
home(~) y luego alDesktop, que está dentro de tu directoriohome(~). -
Crear una carpeta en el directorio
Desktop:Ahora, en el directorio
Desktop, vas a crear una carpeta llamadamirepo. Para esto, usa el comandomkdir:mkdir mirepo
Esto creará la carpeta
mirepodentro deDesktop. -
Moverse dentro de la nueva carpeta:
Ahora, para entrar en la carpeta
mirepoque acabas de crear, usas el comandocdnuevamente:cd mirepoEste comando te llevará a la carpeta
mirepodentro deDesktop, y podrás empezar a trabajar en ella. -
Volver al directorio anterior con
cd ..
Si en algún momento quieres volver al directorio anterior, simplemente escribe:
cd ..El comando cd .. te lleva al directorio padre del directorio en el que estás. En este caso, si estás dentro de mirepo, al usar cd .., regresarías al directorio Desktop.
A continuación, puedes ver un ejemplo visual de cómo se utilizan estos comandos:
Es importante aclarar que los comandos mencionados hasta ahora son comandos de Bash, no de Git. 🖥️ Estos comandos permiten interactuar con el sistema de archivos, como listar archivos 📂, cambiar de directorio 📁, crear carpetas 🗂️ y más. Además, a medida que se avanza, es posible aprender otros comandos de Bash que serán útiles para complementar el trabajo con Git. 💡
Con esta base sólida sobre cómo navegar en la terminal, ¡ha llegado el momento de explorar los comandos de Git! 🚀👨💻 Estos serán herramientas clave para gestionar proyectos y colaborar de forma eficiente. Algunos de los comandos de Git que utilizaremos son:
git init: Inicializando tu repositorio.git status: Ver el estado actual del repositorio.git add: Agregar archivos al staging area.git commit: Crear un nuevo commit.git log: Ver el historial de confirmaciones en el repositorio.git diff: Muestra qué cambios has hecho en los archivos desde el último commit.git branch: Crear y gestionar ramas.git checkout: Cambiar de rama.git merge: Fusionar ramas.
Con estos comandos, se puede empezar a trabajar con Git y organizar proyectos de manera eficiente. ¡Manos a la obra! 💪"
Cuando se trabaja con Git, lo primero que se necesita hacer es crear un repositorio para el proyecto. Esto se logra con el comando git init. Este comando convierte el directorio actual en un repositorio de Git, permitiendo rastrear los cambios en los archivos y mantener un control de versiones en el proyecto.
💡 Hint: ¿Qué es un repositorio? 🤔
Un repositorio (o repo, como se le llama de forma abreviada) es simplemente un lugar donde Git guarda toda la información sobre el proyecto. Dentro del repositorio, Git almacena todos los archivos que forman el proyecto, un historial completo de todos los cambios realizados y la información sobre las versiones de esos archivos. Gracias a esta estructura, es posible revertir a versiones anteriores si es necesario o hacer un seguimiento de cómo ha evolucionado el proyecto a lo largo del tiempo.
Al ejecutar git init, se crea un repositorio vacío en el directorio actual. Esto permite comenzar a agregar archivos y registrar todos los cambios que se realicen. Este repositorio proporciona la infraestructura necesaria para gestionar el proyecto con Git. En la siguiente práctica Práctica #1 se explicará en detalle cómo funciona.
En esta práctica, vamos a crear un repositorio de Git desde cero. El objetivo es aprender a inicializar un repositorio en tu computadora, organizando el proyecto de una manera eficiente desde el principio. Vamos a crear una carpeta (o directorio) llamada mirepo en el escritorio, y dentro de esa carpeta, inicializaremos nuestro repositorio Git con el comando git init. De esta manera, Git comenzará a rastrear y gestionar los archivos y cambios dentro de esa carpeta. 📂
Específicamente, vamos a seguir estos pasos:
- Comenzaremos en el directorio home de tu sistema.
- Desde allí, navegaremos al directorio Desktop (escritorio).
- En el escritorio, crearemos una carpeta llamada
mirepopara alojar nuestro repositorio. - Dentro de esa carpeta, inicializaremos un repositorio Git con el comando
git init. - Finalmente, verificaremos que Git haya creado correctamente el repositorio mostrando la carpeta oculta
.git.
Una vez completados estos pasos, tendrás tu repositorio listo para empezar a trabajar en tu proyecto. 🚀
Ahora sí, empecemos con los pasos detallados:
-
Comienza en tu directorio home
Abre tu terminal y empieza desde tu directorio home con el siguiente comando:cd ~
Este comando te llevará a tu directorio home, el lugar donde se encuentran todas tus carpetas de usuario. 🏡
-
Accede al directorio Desktop
Ahora, navega a tu directorio Desktop (escritorio) donde vamos a crear la carpeta para nuestro repositorio:cd DesktopEste comando te moverá a la carpeta de tu escritorio, donde normalmente se encuentran tus archivos y carpetas principales. 💻
-
Crea una carpeta para tu proyecto
Vamos a crear una nueva carpeta llamadamirepopara alojar nuestro repositorio. Este será el directorio donde gestionaremos todos los archivos relacionados con nuestro proyecto. Para esto, utilizamos el comandomkdir:mkdir mirepo
Este comando crea una carpeta llamada
mirepodentro del escritorio. 🗂️ -
Accede a la carpeta recién creada
Ahora que ya tienes la carpetamirepo, entra dentro de ella para inicializar el repositorio de Git:cd mirepo¡Ya estás dentro de la carpeta donde se creará el repositorio! 🔑
-
Inicializa el repositorio con
git init
Ahora, vamos a inicializar el repositorio en la carpetamirepocon el comandogit init. Esto convierte la carpeta en un repositorio Git, es decir, en un lugar donde Git empezará a rastrear todos los cambios de archivos y versiones:git init
La salida que verás será algo como:
Initialized empty Git repository in C:/Users/Portatil/Desktop/mirep o/.git/Esto significa que Git ha creado una nueva carpeta oculta llamada
.gitdentro demirepo. Esta carpeta es donde Git guarda toda la información sobre el historial y los cambios de tu proyecto. 🎉 -
Verifica que el repositorio se ha creado correctamente
Para asegurarte de que el repositorio se ha creado correctamente, usa el comandols -apara ver todos los archivos, incluidos los ocultos. Deberías ver la carpeta.git, que es clave para el funcionamiento de Git:ls -a
La salida será algo así:
. .. .gitLa carpeta
.gites donde Git almacena toda la información sobre el historial de tu repositorio.[!CAUTION]
La carpeta
.gitcontiene toda la información crucial sobre el historial de tu repositorio, como los commits, las ramas y las configuraciones. ¡No la elimines ni la modifiques manualmente! Esto podría romper tu repositorio y hacer que pierdas todo el historial de cambios."
Con el comando git init, has creado un repositorio vacío en tu carpeta mirepo dentro del escritorio. A partir de aquí, puedes empezar a agregar archivos y registrar tus cambios con Git. ¡Todo está listo para que empieces a trabajar con tu proyecto y a gestionar tu código de manera eficiente! 🚀📂
A continuación, te muestro un ejemplo visual de cómo se verá tu Git Bash después de haber ejecutado todos estos comandos:
El comando git status permite ver el estado del repositorio en cualquier momento. Te muestra información útil, como qué archivos han sido modificados, cuáles están listos para ser confirmados (en el área de preparación), y cuáles no están siendo rastreados por Git. Es una excelente forma de asegurarse de que sabes en qué estado se encuentra el repositorio antes de proceder con más acciones.
Note
En la Práctica #2, se aplicará este comando para verificar el estado del repositorio y decidir qué pasos seguir.
El comando git add permite preparar los archivos para ser confirmados en el historial de Git. Al agregar archivos al staging area, seleccionas específicamente qué cambios deseas incluir en el próximo commit. Se pueden añadir archivos individualmente o todos los archivos modificados con un solo comando.
Note
En la Práctica #2, este comando se utilizará para agregar los archivos modificados al staging area, listos para ser confirmados.
El comando git commit es utilizado para guardar los cambios en el repositorio de manera permanente. Cada vez que se hace un commit, se crea un punto de referencia en el historial del proyecto. Es recomendable acompañar cada commit con un mensaje descriptivo que explique los cambios realizados, ya que esto facilita el seguimiento de la evolución del proyecto.
Note
En la Práctica #2, se aplicará este comando para registrar los cambios realizados y mantener un historial claro de las modificaciones del proyecto.
Warning
Esta práctica es una continuación de la Práctica #1 🖥️ donde configuramos nuestro repositorio y aprendimos a inicializar Git con git init. Asegúrate de haber completado la primera práctica antes de comenzar esta, ya que usaremos el repositorio creado anteriormente y continuaremos trabajando sobre los mismos archivos.
En esta práctica, vamos a continuar con el proyecto que iniciamos en la práctica anterior, donde ya creamos un directorio mirepo y lo inicializamos como un repositorio Git utilizando el comando git init. Ahora, aprenderemos cómo agregar archivos al repositorio usando el comando git add y entenderemos el concepto de stage en Git.
- Crear dos archivos vacíos dentro del directorio
mirepollamadofrutas.txtyciudades.txt. - Verificar el estado de estos archivos con el comando
git status, para ver que Git los reconoce como archivos no rastreados. - Agregar estos archivos al stage usando el comando
git add. El stage es un área intermedia donde Git guarda los cambios antes de confirmarlos con un commit. - Hacer un commit con un mensaje que describa el cambio realizado.
- Verificar nuevamente el estado con
git statuspara asegurarnos de que los cambios han sido confirmados.
Primero, asegurémonos de que estamos ubicados en el directorio mirepo, donde ya inicializamos el repositorio con git init. Si no estás allí, sigue estos pasos:
-
Ir a tu directorio home con:
cd ~
Este comando te llevará a tu directorio home, donde están tus carpetas de usuario. 🏡
-
Acceder al directorio Desktop:
cd DesktopEste comando te lleva al escritorio, donde tenemos la carpeta
mirepo. 💻 -
Entrar en el directorio mirepo:
cd mirepoAhora estás dentro de la carpeta
mirepo, donde ya inicializamos el repositorio congit init. ¡Listo para seguir con la práctica! 🔑
💡 Hint: Accede al directorio en un solo paso
Puedes acceder a tu directorio mirepo con un solo comando, simplificando todo el proceso de ir al directorio home, acceder a Desktop y entrar a la carpeta mirepo:
cd ~/Desktop/mirepoAhora vamos a crear dos archivos vacíos llamados frutas.txt y ciudades.txt con el comando touch:
touch frutas.txt ciudades.txtEsto crea los archivos vacíos en el directorio mirepo.
Después de ejecutar el comando anterior, verifica que los archivos se hayan creado correctamente con ls:
lsLa salida debería ser algo como esto:
frutas.txt ciudades.txtAhora vamos a ver cómo Git detecta esos archivos con el comando git status:
git statusLa salida será algo como esto:
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
frutas.txt
ciudades.txt
nothing added to commit but untracked files present (use "git add" to track)Git nos indica que los archivos frutas.txt y ciudades.txt son no rastreados (untracked). Esto significa que Git los ha detectado, pero aún no los está siguiendo para llevar un control de sus cambios. Necesitamos agregarlos al stage para que Git comience a hacer un seguimiento de ellos.
El siguiente paso es agregar los archivos al stage. Para agregar los archivos frutas.txt y ciudades.txt al stage, usamos el siguiente comando git add:
git add frutas.txt ciudades.txt💡 Hint: ¿Qué es el Stage en Git?
El stage es una especie de área intermedia donde colocamos los archivos que queremos que Git registre en la siguiente versión del proyecto. Es un lugar donde podemos preparar los archivos antes de confirmarlos (hacer un commit). Cuando agregamos un archivo con git add, lo estamos moviendo al stage, lo que le indica a Git que queremos que se tenga en cuenta para la siguiente confirmación. 📋
Así que, el stage nos da control sobre qué archivos formarán parte del commit que vamos a hacer, permitiéndonos decidir qué cambios incluir en nuestra próxima versión del proyecto.
Para ver qué archivos están en el stage, puedes usar el comando git status. Esto te mostrará los archivos que están listos para ser confirmados (commiteados) y te dará una vista general de los cambios en tu repositorio. 🧐
💡 Hint: ¿Qué significa hacer un Commit?
Un commit es el proceso de confirmar los cambios que hemos agregado al stage, creando una versión fija de esos archivos. Cuando haces un commit con git commit, Git guarda los cambios en el historial del repositorio, lo que te permite regresar a esa versión en el futuro si es necesario. 📅
Es como tomar una "foto" de tu proyecto en ese momento. A partir de ese momento, cualquier cambio posterior no afectará ese commit, y podrás regresar a esa versión cuando lo necesites. Además, cada commit tiene un mensaje que describe qué cambios se hicieron, ayudándote a llevar un historial claro de la evolución de tu proyecto.
Ahora, vamos a ejecutar git status nuevamente para verificar que los archivos frutas.txt y ciudades.txt han sido agregados al stage. Deberíamos ver algo así:
git statusLa salida será:
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: frutas.txt
new file: ciudades.txtEsto significa que los archivos están ahora en el stage, listos para ser confirmados en el próximo commit. 🎉
Ahora que los archivos están en el stage, vamos a confirmarlos con el comando git commit. Esto guarda los archivos en el historial de Git. Vamos a agregar un mensaje al commit para describir qué cambios estamos guardando:
git commit -m "Archivos frutas.txt y ciudades.txt vacíos"Este comando confirma los archivos en el repositorio con el mensaje "Archivos frutas.txt y ciudades.txt vacíos". Git genera una salida similar a la siguiente:
[master (root-commit) 01ea681] Archivos frutas.txt y ciudades.txt vacíos
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 ciudades.txt
create mode 100644 frutas.txt
🔒 ¿Qué significa 100644? 🧐
El 100644 es un código que Git utiliza para describir los permisos de un archivo en su sistema de control de versiones. Aquí está lo que significa:
- 100: Especifica que el archivo es regular, no un directorio ni un enlace simbólico.
- 644: Indica los permisos de acceso del archivo, que en formato octal se desglosan así:
- 6 (propietario): Permisos de lectura y escritura (
rw-). - 4 (grupo): Permisos de solo lectura (
r--). - 4 (otros): Permisos de solo lectura (
r--).
- 6 (propietario): Permisos de lectura y escritura (
En resumen, 100644 muestra que el archivo tiene permisos de lectura y escritura para el propietario y solo lectura para el grupo y otros usuarios. 📜🔐
Este modo es común para archivos regulares y es el estándar para los archivos que no son ejecutables ni directorios. ¡Git se encarga de todo para que no tengas que preocuparte! 😌💻
- [master (root-commit) 01ea681]: La rama actual es
master, y01ea681es el identificador único (hash) del commit que acabas de hacer. - Archivos frutas.txt y ciudades.txt vacíos: El mensaje de commit, que debe describir los cambios realizados, en este caso indica que los archivos
frutas.txtyciudades.txtfueron creados y están vacíos. - 2 files changed: Se modificaron dos archivos.
- 0 insertions, 0 deletions: No se agregaron ni eliminaron líneas, ya que los archivos estaban vacíos.
- create mode 100644: Se crearon los archivos
ciudades.txtyfrutas.txt, con permisos de archivo estándar (100644).
😅 Tip: ¿Te diste cuenta de que el mensaje del commit no es el que querías? No te preocupes, es posible corregirlo fácilmente
Si te diste cuenta de que cometiste un error en el mensaje de tu último commit, no te preocupes, ¡tienes una segunda oportunidad! Puedes cambiar el mensaje del commit más reciente con el comando git commit --amend. Así, podrás corregirlo sin necesidad de crear un nuevo commit.
git commit --amendEste comando abrirá tu editor de texto predeterminado y te permitirá editar el mensaje del commit.
Si prefieres no abrir el editor, puedes modificar el mensaje directamente desde la terminal con:
git commit --amend -m "Nuevo mensaje para el commit"Cada comando en Git construye la historia de tu proyecto. Acabas de hacer tu primer commit (root-commit), que marca el inicio de todo. Para facilitarte la comprensión, aquí tienes un grafo que te ayudará a entender mejor lo que acabas de hacer:
Finalmente, vamos a ejecutar git status una vez más. Veremos que ya no hay cambios pendientes:
git statusLa salida será:
On branch master
nothing to commit, working tree cleanEsto significa que todos los cambios han sido confirmados y ahora no hay nada pendiente en el directorio de trabajo. 🧹
git add: Este comando coloca los archivos en el stage, lo que significa que Git los prepara para ser confirmados en el siguiente commit.- El Stage: Es una área intermedia en Git donde colocamos los cambios antes de ser confirmados. Los archivos deben estar en el stage antes de ser confirmados (committed).
git status: Este comando nos ayuda a ver qué archivos están en el stage y qué archivos necesitan ser agregados.
Para que tengas una mejor referencia, aquí te dejo una imagen que muestra cómo debería verse tu Git Bash después de haber ejecutado todos estos comandos:
El comando git log permite ver el historial de confirmaciones (commits) de tu repositorio. Te muestra una lista detallada de todos los commits realizados hasta el momento, junto con información relevante como el autor, la fecha y el mensaje asociado a cada commit. Este comando es útil para revisar el historial de tu proyecto y entender qué cambios se han hecho a lo largo del tiempo.
Note
En la Práctica #3, este comando se utilizará para explorar el historial de confirmaciones y entender cómo ha evolucionado tu proyecto.
El comando git diff permite ver las diferencias entre tu versión actual de los archivos y la última confirmación. Este comando es útil para revisar los cambios que has realizado antes de decidir si deseas agregarlos al área de preparación o hacer un commit. Muestra una comparación línea por línea de los archivos modificados.
Note
En la Práctica #3, se utilizará este comando para ver las diferencias entre los cambios realizados y el último commit, ayudando a decidir qué archivos agregar al staging area.
Warning
Esta práctica se basa en lo aprendido en las Práctica #1 🖥️ y Práctica #2 📝, por lo que es importante haber completado esas prácticas antes de continuar. En esta sección, utilizaremos el repositorio y los archivos que ya creamos y modificamos en los pasos anteriores, para explorar cómo revisar el historial de cambios y comparar diferencias en los archivos.
En esta práctica aprenderás a usar git log para explorar el historial de commits y git diff para comparar los cambios en tus archivos antes y después de agregarlos al stage. Comenzaremos navegando al repositorio, editando los archivos frutas.txt y ciudades.txt, y utilizando git diff para ver las diferencias. Luego, agregaremos los archivos al stage para realizar un nuevo commit, lo que nos permitirá explorar el historial de commits con git log.
Abre la terminal y navega al repositorio en tu escritorio:
cd ~/Desktop/mirepoAgrega dos frutas al archivo frutas.txt y dos ciudades al archivo ciudades.txt:
echo "Manzana" >> frutas.txt
echo "Banana" >> frutas.txt
echo "Nueva York" >> ciudades.txt
echo "Tokio" >> ciudades.txt Antes de agregar los archivos al stage, puedes usar git diff para ver qué cambios has realizado en los archivos desde el último commit. Esto es útil para revisar qué modificaciones has hecho.
git diffSalida esperada:
diff --git a/ciudades.txt b/ciudades.txt
index e69de29..9d53851 100644
--- a/ciudades.txt
+++ b/ciudades.txt
@@ -0,0 +1,2 @@
+Nuevo York
+Tokio
diff --git a/frutas.txt b/frutas.txt
index e69de29..d342878 100644
--- a/frutas.txt
+++ b/frutas.txt
@@ -0,0 +1,2 @@
+Manzana
+BananaAhora, vamos a agregar los archivos al stage con git add. Esto prepara los cambios para ser confirmados en el siguiente commit:
git add frutas.txt ciudades.txtTip
El comando git add . agrega todos los archivos modificados en tu directorio de trabajo (excepto los que están ignorados por .gitignore) al área de preparación (staging area). Es una forma rápida de incluir todos los cambios sin tener que agregar archivo por archivo.
git add .Warning
Aunque es una opción muy común, usar git add . puede no ser la mejor opción, ya que podría agregar archivos no deseados al commit. Es preferible ser más selectivo al agregar archivos al área de preparación para asegurarte de que solo los cambios relevantes sean incluidos.
Tip
En lugar de git add ., usa git add -u si solo deseas agregar los archivos modificados y eliminados que Git ya rastrea, sin incluir archivos nuevos no rastreados. Este comando es útil para asegurarte de que solo los cambios relevantes (sin nuevos archivos) sean parte del commit, evitando así cometer errores.
Aquí tienes un truco que lo hace todo en un solo comando. Lo mejor de todo: nadie tiene que saberlo. 🤫
git commit -am "subiendo todo"Este comando es como si hicieras primero un
git add -upara agregar todos los archivos modificados que ya están siendo rastreados por Git y luego ungit commit -m "subiendo todo"para hacer el commit con el mensaje que hayas especificado. Todo se hace de una vez.
Usa git status para confirmar que los archivos están en el stage y listos para ser confirmados:
git statusSalida esperada:
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: frutas.txt
modified: ciudades.txt
Si ahora ejecutas git diff, notarás que no muestra nada. Esto es porque los cambios ya están en el stage, listos para el commit. git diff solo muestra las diferencias entre el directorio de trabajo y el último commit.
git diffSalida esperada (vacía):
(no output)
Si quieres ver las diferencias entre los archivos en el stage y el último commit, usa git diff --staged. Esto te muestra los cambios listos para ser confirmados.
git diff --stagedSalida esperada:
diff --git a/ciudades.txt b/ciudades.txt
index e69de29..9d53851 100644
--- a/ciudades.txt
+++ b/ciudades.txt
@@ -0,0 +1,2 @@
+Nuevo York
+Tokio
diff --git a/frutas.txt b/frutas.txt
index e69de29..d342878 100644
--- a/frutas.txt
+++ b/frutas.txt
@@ -0,0 +1,2 @@
+Manzana
+BananaAhora, realiza el commit con los cambios que hemos preparado en el stage. Añade un mensaje explicando lo que hicimos:
git commit -m "Agregué dos frutas y dos ciudades a los archivos frutas.txt y ciudades.txt respectivamente"Salida esperada:
[master f09e9ad] Agregué dos frutas y dos ciudades a los archivos
frutas.txt y ciudades.txt respectivamente
2 files changed, 4 insertions(+)
A continuación, te mostramos el grafo que ilustra el commit recién realizado:
Explora el historial de commits con diferentes opciones:
- Ver el historial estándar:
Salida esperada:
git log
commit f09e9adb158aefec03fc1bc79bec17f4772e2e30 (HEAD -> master)
Author: Profesorcito <yoan.pinzon@javerianacali.edu.co>
Date: Sun Jan 19 09:41:59 2025 -0500
Agregué dos frutas y dos ciudades a los archivos frutas.txt y
ciudades.txt respectivamente
commit 01ea681636c7a5964a3e540a32c611a0fdf5cc3d
Author: Profesorcito <yoan.pinzon@javerianacali.edu.co>
Date: Sat Jan 18 22:43:40 2025 -0500
Archivos frutas.txt y ciudades.txt vacíos
git log --onelineSalida esperada:
f09e9ad (HEAD -> master) Agregué dos frutas y dos ciudades a los
archivos frutas.txt y ciudades.txt respectivamente
01ea681 Archivos frutas.txt y ciudades.txt vacíos
💡 Hint: Opciones adicionales de git log
Con git log no solo puedes ver el historial de commits de manera básica, sino que también tienes varias opciones útiles para personalizar la salida:
-
--graph: Muestra el historial de commits de forma visual, representando las ramas y merges con un gráfico en el terminal.
Ejemplo:git log --graph
-
--decorate: Añade información sobre las referencias (como las ramas) junto con los commits.
Ejemplo:git log --decorate
-
--oneline: Muestra los commits en una sola línea, facilitando una vista más compacta del historial.
Ejemplo:git log --oneline
-
--author="nombre": Filtra los commits para mostrar solo los hechos por un autor específico.
Ejemplo:git log --author="Profesorcito"
Además, una combinación común y útil sería usar --graph, --decorate, y --oneline para obtener una vista compacta y visual del historial, mostrando las ramas y los commits en una sola línea:
Ejemplo combinado:
git log --oneline--graph --decorate Cada entrada de git log incluye:
- Hash del commit: Identificador único del commit (ejemplo:
f09e9ad). - Autor: Nombre y correo de la persona que realizó el commit.
- Fecha: Cuándo se realizó el commit.
- Mensaje: Descripción del cambio realizado.
Aquí tienes una imagen que muestra cómo debería verse tu Git Bash después de ejecutar todos los comandos de esta práctica:
El comando git branch se utiliza para crear, listar y gestionar ramas dentro de un repositorio de Git. Las ramas permiten trabajar en nuevas características o correcciones sin afectar el código principal. Con git branch, puedes ver todas las ramas existentes en tu repositorio y crear nuevas ramas para desarrollar nuevas funcionalidades de manera aislada.
Note
En la Práctica #4, se aplicará este comando para crear y gestionar ramas en tu proyecto, permitiéndote trabajar en diferentes versiones del código.
El comando git checkout se utiliza para cambiar entre ramas dentro de un repositorio de Git. Cuando usas este comando, Git actualizará tu área de trabajo a la rama seleccionada, permitiéndote trabajar en una versión específica del código. Es útil para cambiar de contexto entre diferentes funcionalidades o versiones sin perder el progreso realizado.
Note
En la Práctica #4, este comando se utilizará para cambiar entre ramas y trabajar en distintas funcionalidades de tu proyecto sin conflictos.
Warning
Esta práctica sigue sobre lo aprendido en las Práctica #1 🖥️, Práctica #2 📝 y Práctica #3 🔍. Es fundamental que hayas completado todas estas prácticas para aprovechar al máximo esta sección. En esta práctica, exploraremos cómo gestionar diferentes ramas dentro del repositorio creado en los ejercicios anteriores, permitiéndote manejar múltiples versiones del proyecto de manera eficiente.
En esta práctica aprenderás a trabajar con ramas en Git usando los comandos git branch y git checkout. Verás cómo crear y moverte entre ramas, realizar cambios en cada una, y confirmar esos cambios con git commit. Además, comprobarás cómo las modificaciones se mantienen separadas entre ramas, permitiendo alternar entre ellas fácilmente. ¡Vamos a organizar y gestionar tu repositorio como un pro! 🚀
Primero, accedemos al repositorio donde trabajaremos:
cd ~/Desktop/mirepoAgregamos dos frutas y dos ciudades a los archivos existentes frutas.txt y ciudades.txt:
echo "Naranja" >> frutas.txt
echo "Fresa" >> frutas.txt
echo "París" >> ciudades.txt
echo "Londres" >> ciudades.txt Salida esperada: No hay salida visible tras usar echo.
Añadimos los cambios al stage y realizamos un commit:
git add frutas.txt ciudades.txt
git commit -m "Archivos con cuatro frutas y cuatro ciudades"Salida esperada del commit:
[master be45620] Archivos con cuatro frutas y cuatro ciudades
2 files changed, 4 insertions(+)
Aquí tienes el grafo que refleja la evolución del repositorio con el tercer commit registrado:
Creamos una nueva rama llamada ramab y nos movemos a ella:
git branch ramab
git checkout ramabSalida esperada del checkout:
switched to branch 'ramab'
💡 Hint: Atajo con -b
Cuando utilizas git checkout -b <nombre_de_la_rama>, creas y cambias directamente a una nueva rama en un solo paso. Esto te ahorra tener que ejecutar dos comandos separados:
- Sin
-b(más pasos):git branch nueva-rama git checkout nueva-rama
- Con
-b(un solo paso):git checkout -b nueva-rama
Esto no solo es más rápido, sino que también reduce el riesgo de olvidarte de cambiar a la nueva rama tras crearla. 🚀
💡 Tip: ¡Ubícate rápido!
Si quieres saber en qué rama estás, solo ejecuta:
git branchEste comando te muestra todas las ramas de tu repositorio y marca la rama activa con un asterisco (*). Por ejemplo:
master
* ramab
Así sabrás al instante que estás trabajando en la rama ramab.
En la nueva rama:
Agregamos tres frutas y tres ciudades a los archivos existentes:
echo "Piña" >> frutas.txt
echo "Mango" >> frutas.txt
echo "Durazno" >> frutas.txt
echo "Madrid" >> ciudades.txt
echo "Roma" >> ciudades.txt
echo "Berlín" >> ciudades.txt Creamos un nuevo archivo llamado paises.txt con cuatro países:
touch paises.txt
echo "Colombia" >> paises.txt
echo "México" >> paises.txt
echo "Francia" >> paises.txt
echo "Japón" >> paises.txt git statusSalida esperada del git status:
On branch ramab
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working dire
ctory)
modified: ciudades.txt
modified: frutas.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
paises.txt
no changes added to commit (use "git add" and/or "git commit -a")
- "On branch ramab": Estás trabajando en la rama llamada
ramab. - "Changes not staged for commit": Git detectó modificaciones en dos archivos:
ciudades.txtyfrutas.txt, porque le hemos agregado tres items a cada uno, pero esos cambios no están listos para ser confirmados (no están en el stage). - "Untracked files": Git encontró un archivo nuevo llamado
paises.txtque no está siendo rastreado, es decir, no está incluido en el control de versiones aún. - "no changes added to commit": No hemos puesto ningún cambio ni archivo en el stage, por lo que no hay nada listo para confirmar.
git add frutas.txt ciudades.txt paises.txtgit statusSalida esperada del git status:
On branch ramab
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: ciudades.txt
modified: frutas.txt
new file: paises.txt
- "On branch ramab": Estás trabajando en la rama llamada
ramab. - "Changes to be committed": Los archivos listados están en el área de staging y están listos para ser confirmados (commit).
ciudades.txtyfrutas.txthan sido modificados y sus cambios están preparados para el commit.paises.txtes un archivo nuevo que ahora está siendo rastreado y también está listo para ser confirmado.
git commit -m "Archivos con siete frutas, siete ciudades, y paises.txt con cuatro elementos"Salida esperada del commit:
[ramab 2142e89] Archivos con siete frutas, siete ciudades, y pais
es.txt con cuatro elementos
3 files changed, 10 insertions(+)
create mode 100644 paises.txt
Este grafo muestra el estado actual del repositorio, donde se refleja la creación la ramab y cómo el cuarto commit se ha realizado sobre ella. Ahora puedes ver claramente cómo se ha ramificado el historial de cambios:
En ramab, quitamos la primera fruta y la primera ciudad y agregamos dos países al archivo paises.txt para que todos los archivos queden con seis elementos:
sed -i '1d' frutas.txt
sed -i '1d' ciudades.txt
echo "Italia" >> paises.txt
echo "Argentina" >> paises.txt git statusSalida esperada del git status:
On branch ramab
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working dire
ctory)
modified: ciudades.txt
modified: frutas.txt
modified: paises.txt
no changes added to commit (use "git add" and/or "git commit -a")
git add frutas.txt ciudades.txt paises.txtgit statusSalida esperada del git status:
On branch ramab
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: ciudades.txt
modified: frutas.txt
modified: paises.txt
git commit -m "Tres archivos con seis elementos cada uno"Salida esperada del commit:
[ramab 1f571b5] Tres archivos con seis elementos cada uno
3 files changed, 2 insertions(+), 2 deletions(-)
Este grafo muestra el estado actual del repositorio, destacando el quinto commit, que es el segundo realizado en la nueva rama. Aquí puedes ver cómo el historial de cambios se ha ramificado, con el commit fluyendo sobre esta rama recién creada:
Volvemos a la rama master, revisamos el contenido de los archivos y verificamos que los cambios de ramab no están presentes:
git checkout master
ls
cat frutas.txt ciudades.txtSalida esperada:
Switched to branch 'master'
ciudades.txt frutas.txt
Manzana
Banana
Naranja
Fresa
Nuevo York
Tokio
París
Londres
💡 Hint: ¿Qué hace cat?
El comando cat es de Linux 🐧 (también en Git Bash) y se usa para ver el contenido de archivos en la terminal. Viene de "concatenate" (concatenar) porque originalmente servía para juntar archivos. ¡No tiene nada que ver con un gato! 🐱
Ejemplo:
cat frutas.txt ciudades.txtAsí ves ambos archivos en la terminal, rápido y fácil. 📄👀
Regresamos a ramab para confirmar que los archivos tienen seis elementos cada uno:
git checkout ramab
ls
cat frutas.txt ciudades.txt paises.txtSalida esperada:
Switched to branch 'ramab'
ciudades.txt frutas.txt paises.txt
Banana
Naranja
Fresa
Piña
Mango
Durazno
Tokio
París
Londres
Madrid
Roma
Berlín
Colombia
México
Francia
Japón
Italia
Argentina
En esta práctica aprendiste a:
- Crear y cambiar entre ramas con
git branchygit checkout. - Mantener cambios independientes en ramas diferentes.
- Volver a la rama principal para comparar los contenidos.
Para ayudarte a visualizar el resultado, te dejo esta imagen que muestra cómo debería lucir tu Git Bash después de ejecutar todos los comandos de esta práctica:
Así podrás tener una referencia clara de lo que deberías ver al seguir todos los pasos 😎📊.
El comando git merge se utiliza para combinar los cambios de una rama con otra. Es útil cuando has estado trabajando en una rama separada y deseas integrar esos cambios en otra rama, como la rama principal. Al hacer un git merge, Git fusionará los cambios de ambas ramas, añadiendo los cambios nuevos a la rama actual. Si no hay conflictos, el proceso es automático, pero si hay cambios incompatibles, tendrás que resolver los conflictos manualmente.
Note
En la Práctica #5, este comando se utilizará para fusionar los cambios realizados en diferentes ramas, ayudándote a integrar nuevas funcionalidades o correcciones en la rama principal.
Warning
Esta práctica sigue sobre lo aprendido en las Práctica #1 🖥️, Práctica #2 📝, Práctica #3 🔍 y Práctica #4 🌿, así que asegúrate de haber completado esas antes de continuar. En esta práctica, aprenderás a fusionar cambios de distintas ramas en Git utilizando el comando git merge. Será importante que entiendas bien cómo funcionan las ramas y los commits previos para integrar los cambios correctamente.
El merge permite combinar los cambios de una rama con otra. En esta práctica, aprenderemos a fusionar los cambios de la rama ramab en master usando el comando git merge. Veremos cómo Git maneja los archivos comunes y cómo incorpora los nuevos archivos de una rama a otra.
-
Verificar en qué rama estamos
Antes de hacer cualquier fusión, siempre debemos asegurarnos de estar en la rama a la que queremos traer los cambios. En este caso, debemos estar en la ramamaster. Ejecutamos:git checkout master
Salida esperada:
Switched to branch 'master'
-
Hacer el merge desde
ramab
Ahora que estamos en la ramamaster, vamos a fusionar los cambios de la ramaramabusando el comandogit merge:git merge ramab
Salida esperada:
Updating 2142e89..1f571b5 Fast-forward archivos/frutas.txt | 6 ++++++ archivos/ciudades.txt | 6 ++++++ archivos/paises.txt | 4 ++++ 3 files changed, 16 insertions(+)Como la rama
ramabtiene archivos nuevos y cambios en archivos existentes, Git realizará un fast-forward y traerá los cambios amastersin generar conflictos. Los archivosfrutas.txtyciudades.txtse han mezclado, y el archivopaises.txtse ha agregado amaster. -
Ver los archivos en la rama
master
Después de hacer el merge, podemos listar los archivos para ver cómo se han combinado:ls cat frutas.txt ciudades.txt paises.txt
Salida esperada:
ciudades.txt frutas.txt paises.txt Tokio París Londres Madrid Roma Berlín Banana Naranja Fresa Piña Mango Durazno Colombia México Francia Japón Italia ArgentinaAhora, tenemos el archivo
paises.txt, que estaba enramabpero no enmaster, y también los archivosfrutas.txtyciudades.txtque han sido fusionados. Es posible que ahora el contenido de esos archivos sea diferente al de la ramamasteroriginal.
El comando git merge automáticamente combinará los cambios de los archivos comunes, como frutas.txt y ciudades.txt. Si las modificaciones no se superponen, Git las fusionará sin problemas. Sin embargo, si se han realizado cambios conflictivos en las mismas líneas de estos archivos en ambas ramas, Git marcará un conflicto y necesitarás resolverlo manualmente.
En la siguiente imagen se muestra gráficamente el resultado del merge, donde puedes ver cómo la rama ramab se ha fusionado con la rama master.
El comando git push se utiliza para subir los cambios que has realizado en tu repositorio local a un repositorio remoto 🌐, como GitHub. Esto es fundamental para compartir tus actualizaciones con otros colaborares o para respaldar tu trabajo en un servidor remoto. Cuando ejecutas git push, Git envía los commits de tu rama local al repositorio remoto.
Note
En la Práctica #6, este comando se utilizará para actualizar tu repositorio remoto con los últimos cambios de tu repositorio local, asegurando que el trabajo realizado en tu máquina esté reflejado en GitHub.
💡 Hint: ¿Qué pensar de un estudiante que cree que GitHub es Git? 🤦♂️
Es bastante común que los nuevos programadores confundan GitHub con Git, ya que ambos están muy relacionados, pero no son lo mismo. Si eres uno de esos que aún no ve la diferencia, no te preocupes. Esta confusión es más común de lo que parece, y está bien no tenerlo claro al principio. Vamos a explicarlo.
- Git: Es una herramienta de control de versiones. Trabajas con tus repositorios Git en tu máquina local. 💻
- GitHub: Es una plataforma en la nube donde puedes almacenar los repositorios Git que tienes en tu máquina local y colaborar con otros. 🌐
Ahora, para entender por qué ocurre esta confusión, es útil reflexionar sobre algunas razones clave:
-
GitHub es muy popular: GitHub se ha convertido en una de las plataformas más conocidas en el desarrollo de software, tanto que muchos novatos asocian la palabra "Git" directamente con GitHub. Al buscar tutoriales o ejemplos de proyectos, la mayoría se encuentran en GitHub, lo que puede llevar a pensar que Git y GitHub son lo mismo.
-
Falta de contexto inicial: En muchos casos, cuando comienzas a aprender programación, te enseñan Git y GitHub casi al mismo tiempo. Sin una explicación clara de la diferencia entre ambos, es fácil caer en la idea de que Git es solo una parte de GitHub, o una característica adicional.
-
GitHub hace que Git sea más accesible: GitHub facilita mucho el uso de Git. Subir proyectos, clonar repositorios y colaborar en equipo se vuelve muy sencillo con su interfaz visual. Esto puede hacer que algunos olviden que Git es una herramienta independiente que se puede usar localmente, sin necesidad de GitHub.
-
El nombre "GitHub": El hecho de que el nombre de la plataforma incluya "Git" puede llevar a pensar que GitHub es una extensión de Git. Sin embargo, GitHub es solo una plataforma donde puedes almacenar y gestionar los repositorios Git en la nube, pero Git en sí mismo no depende de GitHub.
-
Usuarios novatos buscando soluciones fáciles: Muchos programadores principiantes buscan herramientas que hagan su vida más fácil, y GitHub parece ser una solución todo en uno. La interfaz amigable y las opciones de colaboración pueden hacer que se confunda la idea de tener un repositorio "en GitHub" con tener un repositorio "en Git", sin entender que son conceptos diferentes.
En resumen, la confusión entre Git y GitHub proviene principalmente de la popularidad de GitHub, la falta de explicación en los primeros pasos de aprendizaje y cómo GitHub simplifica el uso de Git. Pero no te preocupes, a medida que sigas aprendiendo, la diferencia se volverá mucho más clara. ¡Todo a su tiempo! 😄
💡 Hint: Otros servicios en la nube 💻☁️
Además de GitHub, existen otras plataformas populares para almacenar y gestionar repositorios Git en la nube:
-
GitLab: Al igual que GitHub, GitLab te permite almacenar tus repositorios, pero ofrece aún más opciones como integración continua (CI/CD) y gestión de proyectos. Además, puedes usarlo tanto en la nube como instalarlo de manera privada en tu propio servidor. 🔄
Sitio web: https://gitlab.com -
Bitbucket: Este servicio está más enfocado en entornos empresariales. Además de almacenar repositorios, Bitbucket se integra muy bien con herramientas como Jira para la gestión de proyectos y seguimiento de tareas, lo que lo hace ideal para equipos de trabajo más grandes. 🧑💻
Sitio web: https://bitbucket.org -
SourceForge: Aunque ha perdido algo de popularidad en comparación con GitHub, sigue siendo una opción viable para proyectos de código abierto. Ofrece funcionalidades similares a las de GitHub y GitLab, pero con una comunidad más pequeña. 💾
Sitio web: https://sourceforge.net
Warning
Esta práctica sigue sobre lo aprendido en las Práctica #1 🖥️, Práctica #2 📝, Práctica #3 🔍, Práctica #4 🌿 y Práctica #5 🔗, así que asegúrate de haber completado esas antes de continuar. En esta práctica, aprenderás a subir tus cambios al repositorio remoto usando el comando git push.
El comando git push es el paso final para compartir tu trabajo con el mundo 🌍. Vamos a practicar cómo subir los cambios de una rama local al repositorio remoto.
-
Crear una cuenta en GitHub
- Primero, abre GitHub y regístrate con tu correo. Si ya tienes una cuenta, solo inicia sesión.
-
Crear un repositorio en GitHub
- Una vez que estés dentro, haz clic en el botón "New" para crear un nuevo repositorio.
- Dale un nombre a tu repositorio (marcado con un 1️⃣ en rojo en la imagen), por ejemplo, "mirepo", para identificarlo fácilmente.
Note
Es una buena práctica que el nombre del repositorio en GitHub sea el mismo que el de tu carpeta local, aunque no es estrictamente necesario. Esto ayuda a mantener todo más organizado y fácil de identificar.
- Escoge la opción público (recomendado para empezar y compartir), aunque también puedes optar por privado si prefieres que solo tú tengas acceso.
- Deja el resto de las opciones como están por ahora (no marques la opción de crear un README ni ninguna otra configuración adicional).
- Por último, haz clic en "Create repository" (marcado con un 2️⃣ en rojo en la imagen) para finalizar la creación de tu repositorio. 🎉
Tu ventana debería lucir algo así:
Si tu repositorio local no está vinculado a un repositorio remoto, debes configurarlo. Para esto:
-
Una vez que crees tu repositorio en GitHub, busca la sección titulada "…or create a new repository on the command line".
Aquí encontrarás el comando necesario para vincular tu repositorio local al remoto, así como otras opciones que puedes usar con el repositorio. Esta información está diseñada para facilitarte el proceso de configuración.
-
Copia y pega en tu terminal el comando que aparece en esa sección, estando dentro de la carpeta de tu repositorio local. Por ejemplo:
git remote add origin https://github.com/yoanpinzon/mirepo.git
Note
Es más rápido y menos propenso a errores copiar los comandos directamente desde GitHub, ya que incluyen la URL exacta de tu repositorio.
💡 Hint: ¿Cómo verificar si mi repositorio está conectado a un remoto? 🤔
En cualquier momento, puedes verificar si tu repositorio local está conectado a un repositorio remoto utilizando el siguiente comando:
git remote -vSi tu repositorio está conectado al remoto, verás algo como esto:
origin https://github.com/yoanpinzon/mirepo.git (fetch)
origin https://github.com/yoanpinzon/mirepo.git (push) origin: Es el nombre que Git asigna al repositorio remoto cuando lo configuras.fetch: Indica la URL desde la cual Git traerá actualizaciones del repositorio remoto a tu máquina local. Este proceso se realiza con el comandogit pull, que explicaremos a continuación.push: Indica la URL donde Git enviará los cambios desde tu repositorio local al remoto.
Esto confirma que tu repositorio local está conectado al remoto en GitHub en las direcciones indicadas para "fetch" y "push".
💡 Hint: ¿Cómo verificar si tu repositorio está sincronizado con el remoto? 🤔
Puedes usar el comando git status para saber si tu repositorio local está sincronizado con el remoto:
git statusOn branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree cleanOn branch master: Estás trabajando en la ramamaster.Your branch is up to date with 'origin/master': Tu rama local está sincronizada con la ramamasterdel repositorio remoto.nothing to commit, working tree clean: No hay cambios pendientes, todo está actualizado y limpio.
Si tu repositorio no está sincronizado, Git lo indicará de esta manera:
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.Esto quiere decir que el repositorio remoto tiene cambios adicionales que puedes traer a tu repositorio local usando el comando git pull.
Aquí tienes una versión revisada para mejorar la redacción, ortografía y flujo del mensaje:
Warning
Antes de continuar, asegúrate de que la rama principal tenga el mismo nombre en tu repositorio local y remoto. En esta práctica, estamos utilizando master como la rama principal. Si tu repositorio local tiene un nombre diferente (por ejemplo, main), cámbialo a master para evitar errores al hacer push o pull. Usa el siguiente comando para renombrar la rama local:
git branch -m master Si el problema es que en GitHub la rama principal se llama main en lugar master, sigue estos pasos para cambiarla:
- Ve a tu repositorio en GitHub y haz clic en "Settings".
- En el menú lateral, selecciona "General".
- Busca la opción "Default branch" y cámbiala de
mainamaster.
💡 Hint: ¿Cómo cambiar la rama predeterminada en GitHub a master? 🤔
-
Accede a la configuración de tu cuenta en GitHub:
Ve a https://github.com/settings/repositories. -
Busca la sección de "Default branch" (Rama predeterminada):
En esta sección, podrás modificar la rama predeterminada para todos los repositorios que crees en el futuro. -
Cambiar la rama predeterminada:
Cambia el nombre de la rama predeterminada demainamaster. -
Guardar los cambios:
Haz clic en el botón de guardar para aplicar la nueva configuración.
Este cambio solo afectará a los nuevos repositorios. Los repositorios existentes mantendrán su configuración actual.
-
Subir los cambios a GitHub
Para subir tus cambios al repositorio remoto, escribe:
git push -u origin master
💡 Hint: ¿Qué hace el parámetro -u en git push?
El parámetro `-u` establece la relación entre tu rama local `master` y la rama remota `origin/master`, lo que facilita futuras interacciones con Git, ya que Git recordará esta referencia.Usar
-uconfiguraorigincomo el repositorio remoto predeterminado para tu rama local. Esto significa que, en el futuro, solo necesitarás escribirgit pushsin necesidad de especificar el repositorio remoto. 🎯Si es la primera vez que haces un
git push, GitHub te pedirá autenticarte. Aquí es donde puede que veas una ventana emergente que te da la opción de iniciar sesión a través de tu navegador:-
Ventana de inicio de sesión:
Cuando Git detecta que necesitas autenticarte, abre una ventana emergente con un botón que dice algo como "Sign in through your browser". -
Autenticación directa sin pedir más detalles:
En muchos casos, al hacer clic en este botón, GitHub automáticamente te redirige a tu navegador donde ya estás logueado en GitHub, y no te pedirá más detalles. Si ya tienes sesión iniciada en tu navegador, GitHub automáticamente autoriza elgit pushsin solicitar más información.
Si todo va bien, verás algo como esto en la terminal:
Enumerating objects: 26, done. Counting objects: 100% (26/26), done. Delta compression using up to 8 threads Compressing objects: 100% (13/13), done. Writing objects: 100% (26/26), 2.25 KiB | 1.12 MiB/s, done. Total 26 (delta 1), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (1/1), done. To https://github.com/yoanpinzon/mirepo.git * [new branch] master -> master branch 'master' set up to track 'origin/master'. -
Tip
El comando git push -u origin master lo encuentras en GitHub después de crear tu repositorio, en la sección "…or create a new repository on the command line", junto al comando git remote add origin https://github.com/yoanpinzon/mirepo.git que utilizamos arriba.
-
Verificar los cambios en GitHub 🌍
¡Eso es todo! Ahora, solo dirígete a tu repositorio en GitHub y verifica que los cambios se hayan subido correctamente.
A partir de ahora, que ya tenemos nuestro repositorio vinculado con el remoto en GitHub, cada vez que hagamos cambios en los archivos, debemos asegurarnos de que esos cambios se reflejen en el repositorio remoto.
-
Hacemos los Cambios en los Archivos
Vamos a realizar una modificación en los archivos, como por ejemplo, ordenar alfabéticamente los archivos ciudades.txt, frutas.txt y países.txt:$ sort -o ciudades.txt ciudades.txt $ sort -o frutas.txt frutas.txt $ sort -o países.txt países.txt
-
Verificamos Qué Archivos Fueron Modificados
Luego, usamosgit statuspara ver qué archivos han sido modificados:$ git status
Esto nos muestra los archivos que han cambiado y que están listos para ser añadidos al commit.
-
Añadimos los Archivos Modificados
Ahora, añadimos esos archivos modificados congit add:$ git add ciudades.txt frutas.txt países.txt
-
Realizamos el Commit
Registramos los cambios con un mensaje claro, explicando qué cambios hicimos:$ git commit -m "Ordenados los archivos de ciudades, frutas y países" -
Subimos los Cambios al Repositorio Remoto
Finalmente, subimos los cambios al repositorio remoto congit push:$ git push
Esto asegurará que todos los cambios que hicimos en los archivos se reflejen en el repositorio de GitHub.
💡 Hint: ¿git push solo sube la rama en la que estamos? 🤔
Cuando usas
git pushsin ningún modificador, Git sube solo la rama en la que te encuentras al repositorio remoto. Esto significa que los cambios que has realizado en esa rama se subirán al remoto. Por ejemplo, si estás en la ramamastery ejecutasgit push, solo esa rama se actualizará en el remoto.Si quieres subir una rama específica que no es la actual, usas:
git push origin nombre_de_rama
Para subir todas las ramas locales de una vez, puedes usar:
git push --all
Además, si la rama remota no existe aún, Git la creará automáticamente cuando subas tu rama local.
Tip
A partir de ahora, cada vez que hagas cambios en tu repo, asegúrate de reflejarlos en GitHub con estos pasos:
- Modifica los archivos
- Verifica con
git status - Añade con
git add - Confirma con
git commit - Sube con
git push
Tip
Antes de hacer un git push, ejecuta un git pull si ya has realizado un push previo. Esto asegura que tu repositorio local esté sincronizado con los últimos cambios del remoto, evita conflictos y garantiza que no sobrescribas el trabajo de otros colaboradores 🚦.
El comando git pull se utiliza para traer y fusionar los cambios realizados en un repositorio remoto 🌐 hacia tu repositorio local. Es un paso clave para asegurarte de trabajar con la versión más actualizada del código y evitar conflictos al colaborar con otros desarrolladores.
Cuando ejecutas git pull, Git realiza dos operaciones principales:
- Fetch: Descarga los cambios del remoto.
- Merge: Combina esos cambios con la rama activa en tu máquina local.
Note
En la Práctica #7, este comando será fundamental para garantizar que tu trabajo local esté sincronizado con el repositorio remoto, especialmente cuando trabajas en equipo.
¡Entendido! Aquí está la versión modificada, aclarando que el cambio se realiza directamente desde GitHub:
Warning
Asegúrate de haber completado las prácticas previas con mirepo. En esta práctica, aprenderás a usar git pull para actualizar tu repositorio local con los cambios hechos en GitHub, específicamente la inclusión de "Sevilla" en orden alfabético en el archivo ciudades.txt.
El comando git pull permite traer los cambios que se han realizado en el repositorio remoto y fusionarlos con tu repositorio local. Vamos a trabajar con el archivo ciudades.txt, agregando la ciudad "Sevilla" en el orden adecuado desde GitHub, y luego usando git pull para sincronizar esos cambios con tu repositorio local.
-
Realiza el cambio en GitHub
Accede a tu repositorio mirepo en GitHub y abre el archivociudades.txt. Añade la ciudad "Sevilla" en el lugar correspondiente según el orden alfabético, es decir, entre "Roma" y "Tokio". Una vez hecho el cambio, guarda los cambios directamente en GitHub.El archivo
ciudades.txten GitHub debería quedar así:Berlín Londres Madrid París Roma Sevilla TokioNo olvides confirmar los cambios con un mensaje de commit, como:
Agregada la ciudad Sevilla al archivo ciudades.txt -
Traer los cambios del repositorio remoto
Regresa a tu terminal, asegurándote de estar en la ramamaster, y ejecuta:git pull
Note
Como ya hiciste un git push -u origin master, la opción -u establece la rama remota predeterminada, lo que permite que el comando git pull traiga automáticamente los cambios. Si fuera necesario, puedes usar git pull origin master para especificar explícitamente el repositorio y la rama.
Salida esperada:
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (3/3), 1017 bytes | 145.00 KiB/s, done.
From https://github.com/yoanpinzon/mirepo
39cef6b..9371fa5 master -> origin/master
Updating 39cef6b..9371fa5
Fast-forward
ciudades.txt | 1 +
1 file changed, 1 insertion(+)El comando git pull descargará los cambios de GitHub (donde agregaste la ciudad "Sevilla") y los fusionará con tu archivo local ciudades.txt.
-
Verificar los cambios
Después del
git pull, verifica que "Sevilla" esté en el archivociudades.txtcon:cat ciudades.txt
Salida esperada:
Berlín Londres Madrid París Roma Sevilla Tokio
Tip
Usa git pull --rebase si prefieres aplicar tus cambios locales después de los del remoto en lugar de fusionarlos automáticamente. Esto genera un historial más limpio. 🚦
El comando git clone se utiliza para crear una copia exacta de un repositorio remoto (como el de GitHub) en tu máquina local. Al ejecutar este comando, Git se encarga de crear la carpeta correspondiente y descargar todo el contenido del repositorio en ella. ¡No tienes que preocuparte por crear la carpeta tú mismo! 😎
Important
Cuando clonas un repositorio con git clone, no solo obtienes el último commit, sino toda la historia de commits del proyecto. Esto significa que puedes moverte a cualquier versión anterior del proyecto en cualquier momento usando comandos como git checkout <commit-hash> o git checkout <nombre-de-rama>. ¡Esto te permite explorar el código en cualquier punto del tiempo! 🔄
Si solo te interesa la última versión del proyecto, puedes usar
git clone --depth 1. Esto hará que Git solo descargue el último commit del repositorio, ahorrando tiempo ⏱️ y espacio 💾, pero sin acceso al historial completo.
-
Obtener la URL del repositorio
Dirígete a la página del repositorio en GitHub (o en otro servicio similar) y copia la URL del repositorio. En GitHub, puedes encontrar esta URL haciendo clic en el botón verde que dice Code, y luego copiar el enlace. -
Ejecutar el comando
git clone
Una vez tengas la URL, ve a tu terminal y navega hasta el lugar donde quieras que se guarde el repositorio. Luego, ejecuta el siguiente comando:git clone https://github.com/usuario/nombre-del-repositorio.git
Ejemplo:
Si estás clonando el repositorio llamado mirepo de profesorcito, el comando será:
git clone https://github.com/profe/mirepo.gitImportant
Git creará automáticamente una carpeta con el nombre del repositorio (en este caso, mirepo) y descargará todos los archivos dentro de esa carpeta. No es necesario que hagas un mkdir por adelantado.
💡 Hint: ¿Se puede cambiar el nombre de un repositorio al clonarlo? 🤔
Si no quieres que Git cree la carpeta con el nombre del repositorio, puedes darle el nombre que quieras cuando clones el repositorio. Solo tienes que añadir el nombre de la carpeta al final del comando:git clone https://github.com/yoanpinzon/mirepo.git mirepo2Esto clonará el repositorio en una carpeta llamada mirepo2 en lugar de usar el nombre del repositorio (mirepo). ¡Es útil si prefieres organizar las cosas de forma distinta!
💡 Hint: ¿Se puede clonar solo una rama específica de un repositorio? 🌱🤔
Si solo te interesa trabajar con una rama específica, como una rama de desarrollo, puedes clonar únicamente esa rama de la siguiente forma:
git clone --branch ramab https://github.com/yoanpinzon/mirepo.gitAsí, solo se descargará la rama que necesitas, ahorrando espacio y tiempo.
-
Acceder a la carpeta del repositorio clonado
Una vez que el repositorio esté clonado, entra en la carpeta que Git acaba de crear con el siguiente comando:cd mirepo¡Ahora estás dentro de la carpeta del repositorio y listo para trabajar! 🚀
Usa
-bpara clonar y cambiar de rama en un solo paso 🏃♂️💨:git clone -b ramab https://github.com/yoanpinzon/mirepo.gitAhorras el
git checkout ramabposterior. ⏱️
Cuando trabajamos con Git en equipo o en proyectos individuales, es común encontrarnos con conflictos 🔥. Estos ocurren cuando Git no puede fusionar automáticamente los cambios entre dos versiones de un archivo y necesita que el usuario los resuelva manualmente.
Los conflictos pueden aparecer en diferentes situaciones:
Ocurren cuando intentamos fusionar dos ramas y ambas han modificado la misma línea de un archivo.
- Git no puede decidir qué versión conservar y nos pide que resolvamos el conflicto manualmente.
- Se deben editar los archivos afectados y luego confirmar los cambios.
- Este tipo de conflicto será el enfoque de la Práctica #8.
Aparecen cuando intentamos subir cambios (push) al repositorio remoto, pero este ha recibido modificaciones desde la última vez que descargamos el código.
- Git rechaza el
pushpara evitar sobrescribir cambios de otros colaboradores. - Se resuelve trayendo los cambios remotos (
git pull) antes de intentar elpushnuevamente.
Suceden cuando intentamos actualizar nuestro repositorio local con git pull, pero hay cambios sin confirmar en nuestra máquina que entran en conflicto con los cambios del remoto.
- Git no puede fusionar los cambios automáticamente.
- Es necesario guardar o descartar los cambios locales antes de hacer el
pull.
A continuación, en la Práctica #8 daremos un ejemplo completo de cómo manejar conflictos en el caso de un merge.** 🚀
En esta práctica trabajaremos con un archivo llamado cuento.md, donde escribiremos un breve cuento y provocaremos un conflicto en la segunda línea.
- Creamos un repositorio con algunos commits en
master. - Creamos una rama y realizamos un merge sin conflictos.
- Creamos otra rama y editamos la segunda línea del cuento en
mastery en la nueva rama, provocando un conflicto engit merge. - Usamos
git statuspara ver los archivos en conflicto. - Resolvemos el conflicto manualmente y verificamos el resultado con
cat.
📌 Creamos el repositorio en el escritorio (~/Desktop) y entramos en la carpeta:
cd ~/Desktop
mkdir practica-merge
cd practica-merge
git init🔍 Salida esperada:
Initialized empty Git repository in C:/Users/Portatil/Desktop/practica-merge/.git/
¿Qué estamos haciendo aquí?
- Creamos una nueva carpeta
practica-mergeen el escritorio. - Entramos en la carpeta recién creada.
- Inicializamos un repositorio de Git con
git init, lo que nos permitirá realizar seguimiento de los cambios.
📌 Creamos el archivo cuento.md y escribimos la primera línea del cuento:
echo "El bosque era inmenso." > cuento.md
git add cuento.md
git commit -m "Primera línea del cuento"🔍 Salida esperada:
[master (root-commit) 2ae03e5] Primera línea del cuento
1 file changed, 1 insertion(+)
create mode 100644 cuento.md
¿Qué hace este comando?
echo "El bosque era inmenso." > cuento.md→ Crea el archivocuento.mdcon la primera línea del cuento.git add cuento.md→ Agrega el archivo al área de preparación de Git.git commit -m "Primera línea del cuento"→ Guarda el primer commit con la línea inicial del cuento.
📌 Agregamos la segunda línea y hacemos otro commit:
echo "Un zorro curioso lo exploraba." >> cuento.md
git commit -am "Segunda línea del cuento"🔍 Salida esperada:
[master 2cc03df] Segunda línea del cuento
1 file changed, 1 insertion(+)
Explicación:
>>significa agregar texto al archivo sin sobrescribirlo.git commit -am "Segunda línea del cuento"realiza dos acciones en un solo comando:-a→ Agrega automáticamente los archivos ya versionados.-m→ Permite escribir un mensaje en el commit.
📌 Agregamos la tercera línea y hacemos otro commit:
echo "Un día encontró un sendero." >> cuento.md
git commit -am "Tercera línea del cuento"📌 Verificamos el historial con git log --oneline para entender el progreso:
git log --oneline🔍 Salida esperada:
e736bbb (HEAD -> master) Tercera línea del cuento
2cc03df Segunda línea del cuento
2ae03e5 Primera línea del cuento
Explicación:
git log --onelinemuestra el historial de commits de forma compacta.HEAD -> masterindica que estamos en la ramamastery señala el commit más reciente.- Cada línea representa un commit con su identificador único y el mensaje que le dimos.
📌 Creamos una nueva rama ramab:
git checkout -b ramab🔍 Salida esperada:
Switched to a new branch 'ramab'
¿Qué estamos haciendo?
git checkout -b ramab→ Crea una nueva rama llamadaramaby cambia a ella automáticamente.- Ahora podemos hacer cambios en
ramabsin afectarmaster.
📌 Añadimos una nueva línea que no genera conflicto:
echo "El sendero llevaba a un puente." >> cuento.md
git commit -am "Cuarta línea del cuento"📌 Volvemos a master y fusionamos ramab:
git checkout master
git merge ramab🔍 Salida esperada:
Updating e736bbb..c854729
Fast-forward
cuento.md | 1 +
1 file changed, 1 insertion(+)
Explicación:
git checkout master→ Volvemos a la rama principal (master).git merge ramab→ Fusionamos los cambios deramabenmaster.
📌 Verificamos el contenido del archivo después del merge sin conflicto:
cat cuento.md🔍 Salida esperada:
El bosque era inmenso.
Un zorro curioso lo exploraba.
Un día encontró un sendero.
El sendero llevaba a un puente.
¿Por qué no hubo conflicto?
- El cambio en
ramabsolo añadió una línea al final, sin modificar ninguna de las líneas existentes enmaster. - Git pudo combinar ambas versiones sin problemas.
📌 Creamos otra rama llamada ramac:
git checkout -b ramac🔍 Salida esperada:
Switched to a new branch 'ramac'
¿Qué estamos haciendo?
git checkout -b ramac→ Crea una nueva rama llamadaramacy cambia a ella automáticamente.- Vamos a modificar el archivo en esta rama para generar un conflicto más adelante.
📌 Modificamos la segunda línea en ramac usando Notepad:
notepad cuento.md🔹 Editamos la segunda línea del archivo:
Reemplazamos la segunda línea, que originalmente decía "Un zorro curioso lo exploraba.", por "Un zorro veloz lo recorría.".
📌 Guardamos CTRL + S y cerramos Notepad.
📌 Verificamos que la segunda línea cambió correctamente:
cat cuento.md🔍 Salida esperada:
El bosque era inmenso.
Un zorro veloz lo recorría.
Un día encontró un sendero.
El sendero llevaba a un puente.
📌 Confirmamos los cambios en ramac:
git commit -am "Modificada segunda línea en ramac"🔍 Salida esperada:
[ramac 64d01ce] Modificada segunda línea en ramac
1 file changed, 1 insertion(+), 1 deletion(-)
📌 Volvemos a master y modificamos la misma línea:
git checkout master🔍 Salida esperada:
Switched to branch 'master'
notepad cuento.md🔹 Editamos la segunda línea del archivo:
Reemplazamos la segunda línea, que originalmente decía "Un zorro curioso lo exploraba.", por "Un zorro astuto lo habitaba.".
📌 Guardamos CTRL + S y cerramos Notepad.
📌 Verificamos que la segunda línea cambió correctamente en la rama master:
cat cuento.md🔍 Salida esperada:
El bosque era inmenso.
Un zorro astuto lo habitaba.
Un día encontró un sendero.
El sendero llevaba a un puente.
📌 Confirmamos los cambios en master:
git commit -am "Modificada segunda línea en master"🔍 Salida esperada:
[master c023a21] Modificada segunda línea en master
1 file changed, 1 insertion(+), 1 deletion(-)
📌 Intentamos hacer git merge ramac y obtenemos un conflicto:
git merge ramac🔍 Salida esperada:
Auto-merging cuento.md
CONFLICT (content): Merge conflict in cuento.md
Automatic merge failed; fix conflicts and then commit the result.
¡Advertencia!
⚠️ No lo uses en este momento, ya que estás en medio de una práctica y podría interferir con el flujo de trabajo que estás siguiendo. ❌Si durante un merge en Git decides que no quieres continuar, puedes abortarlo en cualquier momento. Para hacerlo, usa el comando:
git merge --abort
📌 Mostramos el contenido del archivo después del conflicto:
cat cuento.md🔍 Salida esperada:
El bosque era inmenso.
<<<<<<< HEAD
Un zorro astuto lo habitaba.
=======
Un zorro veloz lo recorría.
>>>>>>> ramac
Un día encontró un sendero.
El sendero llevaba a un puente.
📌 Explicación:
Cuando Git intenta hacer un merge, pero encuentra cambios en la misma línea en ambas ramas, marca el conflicto en el archivo y nos deja resolverlo manualmente.
<<<<<<< HEAD→ Muestra la versión que está en la rama actual (master).Un zorro astuto lo habitaba.→ Es el texto que estaba enmaster.=======→ Separa las dos versiones en conflicto.Un zorro veloz lo recorría.→ Es el texto que estaba en la ramaramac.>>>>>>> ramac→ Indica que la segunda versión viene de la ramaramac.
Git no puede decidir qué versión mantener, por lo que nos deja resolver el conflicto manualmente.
Important
En resumen, los marcadores de conflicto en Git indican cambios incompatibles:
| Marcador | Indica |
|---|---|
| Comienzo de una versión | <<<<<<< |
| División entre versiones | ======= |
| Comienzo de la otra versión | >>>>>>> |
📌 Ejecutamos git status para ver qué archivos tienen conflictos:
git status🔍 Salida esperada:
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: cuento.md
no changes added to commit (use "git add" and/or "git commit -a")
📌 Explicación:
- Git nos informa que hay archivos en conflicto.
both modified: cuento.mdindica que ambas ramas modificaron el archivo.- Nos sugiere que resolvamos el conflicto y usemos
git addpara marcarlo como resuelto antes de hacer elcommit.
💡 Hint: Usar git diff para ver las diferencias entre ramas antes del merge
En cualquier momento, podemos comparar las diferencias entre las versiones de cuento.md en master y ramac:
git diff master ramac -- cuento.mdExplicación del comando:
git diff: Este comando muestra las diferencias entre dos versiones de un archivo o entre dos ramas.master: Es la primera rama que estás comparando.ramac: Es la segunda rama con la que comparasmaster.--: Es utilizado para indicar que lo que sigue son nombres de archivos o directorios, y no más referencias a ramas o commits. Ayuda a evitar confusiones.cuento.md: Es el archivo específico que estás comparando entre ambas ramas.
🔍 Salida esperada:
diff --git a/cuento.md b/cuento.md
index 7ec8750..648dac7 100644
--- a/cuento.md
+++ b/cuento.md
@@ -1,4 +1,4 @@
El bosque era inmenso.
-Un zorro astuto lo habitaba.
+Un zorro veloz lo recorría.
Un día encontró un sendero.
El sendero llevaba a un puente.📌 Abrimos el archivo en Notepad para editarlo manualmente:
notepad cuento.md🔹 Editamos la línea en conflicto y combinamos ambas versiones:
El bosque era inmenso.
Un zorro astuto y veloz lo exploraba.
Un día encontró un sendero.
El sendero llevaba a un puente.
📌 Guardamos CTRL + S y cerramos Notepad.
📌 Marcamos el archivo como resuelto agregándolo al área de preparación:
git add cuento.md📌 Confirmamos la resolución del conflicto con un nuevo commit:
git commit -m "Conflicto resuelto en cuento.md"🔍 Salida esperada:
[master b01d48b] Conflicto resuelto en cuento.md
Este commit guarda los cambios y completa el merge, dejando el repositorio en un estado limpio sin conflictos pendientes. 🚀
✅ ¡Conflicto resuelto exitosamente! 🎉
| Comando | Descripción |
|---|---|
git init |
Inicializa un nuevo repositorio |
git merge <rama> |
Fusiona una rama con la actual |
git log --oneline |
Muestra el historial de commits |
notepad <archivo> |
Abre un archivo en Notepad |
git status |
Muestra el estado del repositorio y los archivos en conflicto |
git diff master ramac -- <archivo> |
Compara las diferencias entre dos ramas antes del merge |
git add <archivo> |
Marca un archivo como resuelto |
git commit -m "mensaje" |
Confirma la resolución del conflicto |
Aquí tienes una imagen que muestra cómo debería verse tu Git Bash después de ejecutar los comandos de esta práctica, para que tengas una referencia clara de lo que deberías ver:
Git nos permite navegar entre diferentes versiones de nuestro proyecto, ya sea para revisar cambios previos, deshacer errores o incluso recuperar versiones antiguas. En este capítulo, aprenderás cómo moverte en el historial de commits sin perder información.
A lo largo de esta sección, exploraremos tres comandos esenciales:
git checkout <commit>: Para movernos a un commit específico.git reset: Para deshacer commits y regresar a un estado anterior.git revert: Para deshacer cambios sin modificar el historial.
Con estos comandos, podrás viajar en el tiempo dentro de tu repositorio y manejar de forma segura los cambios en tu código.
Git es como una máquina del tiempo para tu código. A veces necesitas retroceder para revisar un cambio, ver cómo estaba tu código hace unos días o depurar errores. Para eso, Git tiene varios atajos geniales para moverte en el historial.
Note
Desde 2019, Git introdujo git switch como una alternativa más clara y específica para cambiar de rama. Aun así, git checkout sigue funcionando y muchos desarrolladores siguen usándolo por costumbre o compatibilidad.
La mayoría de los desarrolladores suelen hacerlo de la siguiente manera:
① Ver el historial en versión corta:
git log --onelineEsto mostrará algo como esto:
* a1b2c3d (HEAD -> master) Fix en validación de formulario
* f6g7h8i Nueva funcionalidad de login
* j9k0l1m Implementación de API
* c2d3e4f Refactorización del código
* g4h5i6j Mejora en la documentación
* k7l8m9n Eliminación de código obsoleto
* p0q1r2s Configuración inicial de CI/CD
* t3u4v5w Agregado soporte para logs
* x6y7z8a Estructura base del proyecto
* b9c0d1e Commit inicial
Aquí, HEAD -> master indica la posición actual de HEAD, es decir, el último commit en la rama master.
② Copiar el hash del commit al que quieres ir.
③ Usar git checkout para moverte a un commit específico:
git checkout c2d3e4fHEAD ahora pasará a estar en c2d3e4f (Refactorización del código).
También es posible retroceder sin necesidad de copiar un hash, usando atajos más rápidos:
✅ Un paso atrás
git checkout HEAD^Si HEAD se encontraba en a1b2c3d, ahora pasará a estar en f6g7h8i (Nueva funcionalidad de login).
Tip
git checkout -Vuelve a la rama o commit anterior en un solo paso. 🔄✨
✅ Dos pasos atrás
git checkout HEAD^^Si HEAD se encontraba en a1b2c3d, ahora pasará a estar en j9k0l1m (Implementación de API).
✅ Tres pasos atrás
git checkout HEAD^^^Si HEAD se encontraba en a1b2c3d, ahora pasará a estar en c2d3e4f (Refactorización del código).
✅ Retroceder N commits
git checkout HEAD~5Si HEAD se encontraba en a1b2c3d, ahora pasará a estar en k7l8m9n (Eliminación de código obsoleto).
✅ Saltar a un commit y retroceder desde ahí
git checkout c2d3e4f
git checkout HEAD^^No importa en qué commit estés, este comando primero te lleva a c2d3e4f (Refactorización del código) y luego retrocede dos commits más, aterrizando en k7l8m9n (Eliminación de código obsoleto).
Hazlo en un solo comando:
git checkout c2d3e4f^^Salta directamente a
c2d3e4fy retrocede dos commits **sin interrupciones. Pero shhh... que esto quede entre nosotros. 🤫
✅ Retroceder desde una rama específica (ramab)
git checkout ramab^^Si HEAD estaba en la punta de la rama ramab, ahora pasará a estar dos commits atrás en la misma rama.
📌 Ejemplo:
git checkout ramab~5Si HEAD estaba en la punta de ramab, ahora pasará a estar cinco commits atrás en la misma rama.
Cuando usas git checkout <commit> o cualquiera de los atajos anteriores, HEAD deja de seguir una rama y se posiciona en un commit específico. Esto se conoce como detached HEAD, y significa que:
✅ Puedes ver el código tal como estaba en ese commit.
❌ No estás en ninguna rama.
Cuando HEAD está "desconectado", no apunta a ninguna rama en particular, sino solo a un commit específico.
Tip: Si quieres modificar el código sin perderlo, crea una nueva rama antes de hacer cambios:
git checkout -b mi-nueva-rama
Después de moverte con git checkout <commit>, Git te lo advertirá con un mensaje como este:
Note: switching to 'c2d3e4f'.
You are in 'detached HEAD' state.
También puedes verificarlo manualmente con:
git statusSi estás en detached HEAD, verás algo como esto:
HEAD detached at c2d3e4f
Si solo querías explorar un commit y regresar, usa:
git checkout master # O la rama en la que estabas antesEsto te devuelve a una rama activa, evitando que Git borre tu trabajo.
Si no recuerdas en qué commit estabas antes, puedes revisar el historial de movimientos con:
git reflogY para volver a una posición anterior reciente:
git checkout HEAD@{N}📌 Ejemplo:
git checkout HEAD@{2} # Regresa a donde estabas hace dos movimientosNote
Linus Torvalds no diseñó Git para ser fácil, sino para ser poderoso. Él mismo dijo que era una herramienta para gente inteligente. 🧠🔥
Important
Ahora piensa bien qué hace el siguiente comando y prepárate para recordarlo en el examen del profesorcito 😏:
git checkout HEAD@{1}