Cómo llevar tu uso de Git al siguiente nivel: Una guía intermedia con tips prácticos y ejemplos de uso #

En esta guía intermedia, exploraremos algunos trucos y consejos avanzados que te ayudarán a optimizar tu flujo de trabajo y evitar errores comunes. Cómo explorar el comando checkout, cómo crear ramas, cómo fusionar ramas, cómo deshacer cambios, cómo ignorar archivos y mucho más.

Te invitamos a nuestro curso gratuito en Youtube 👇🏽👇🏽👇🏽

Recursos #

• Explicación simple git

Ignorando Archivos #

Para no hacer seguimiento de carpetas o archivos, debemos crear el siguiente archivo:

• .gitignore
  Su estructura de ejemplo sería así:

arhivo.js // Ignora el archivo en cuestion
*.js // Ignora todos los arhivos con extensión .js
node_modules/ //Ignora toda la carpeta

Introducción #

• fuente
• Una vez que se ha hecho un commit de los cambios, estos suelen volverse permanentes.
• Utiliza git checkout para desplazarte y revisar el historial de commits.
• git revert es la mejor herramienta para deshacer cambios públicos compartidos.
• git reset es más adecuado para deshacer cambios privados locales.

git log --oneline #

Nos muestra el identificador para poder revisar el historial de commit (Cada confirmación tiene un hash SHA-1 de identificación único.).

git log --oneline

a6d151c (HEAD -> master) 02-h2
a00beae 01-html

git checkout #

Si queremos visitar un commit en específico utilizamos:

git checkout a00beae

Durante el curso normal del desarrollo, HEAD apunta por lo general a la rama main u otra rama local (HEAD -> master), pero, cuando extraes una confirmación anterior, HEAD ya no apunta a una rama, sino que apunta directamente a una confirmación. Este estado recibe el nombre de "HEAD desasociado" (detached HEAD)

a00beae (HEAD) 01-html

Comprobar un commit específico pondrá el repositorio en un estado "HEAD desasociado". Esto significa que ya no estás trabajando en ninguna rama.

git checkout master

¿y si hago un commit? #

En el caso de que visitemos un historial de un commit con checkout y comencemos a realizar cambios a partir de ese momento en el tiempo, nuestro nuevo commit quedará huerfano, no tendrá ninguna rama asociada (recuerden que estamos trabajando en master o main). Por lo tanto siguiendo el mismo ejemplo anterior:

git log --oneline

a6d151c (HEAD -> master) 02-h2
a00beae 01-html

git checkout a00beae

Realizamos cambios en el archivo y guardamos un nuevo commit

git add .
git commit -m "03-huerfano"

Ahora si queremos volver a la rama principal (master o main)

git checkout master

Tomar nota que efectivamente viajamos al último commit pero git nos recomienda hacer una nueva rama para el commit huerfano.

Todavía no vemos como hacer una rama así que lo dejamos hasta acá por el momento.

Master a Main #

• Leer artículo

De forma global

git config --global init.defaultBranch main

Para un único proyecto

git branch -m master main

git reset #

• fuente
• Viaje a través de diferentes commit

Vamos a conocer como podemos movernos entre los diferentes commit que tengamos registrados, Esto es útil si aún no has subido tu commit a GitHub o a otro repositorio remoto., supongamos que tenemos los siguientes commit:

17d793b (HEAD -> master) tercero.html
c97d996 nosotros.html
3f81f17 primer commmit

Viajamos al commit en específico c97d996

git reset --mixed c97d996

Podemos notar que no se restauran los archivos pero quedaron sin seguimiento, verás una "u" en VSCode.

Retrocedamos nuevamente

git reset 17d793b

Ahora vamos a utilizar un método destructivo: viajamos al commit en específico c97d996 y eliminamos los cambios futuros

git reset --hard c97d996

En caso de resturar los cambios podemos utilizar reflog: muestra todos los cambios incluso si borramos los commit

git reflog

Viajamos al commit en específico 17d793b y podemos restaurar los archivos

git reset --hard 17d793b

Para mayor información visite: Click aquí

Cuidado con Reset #

Ambos comandos git revert y git reset, deshacen commits anteriores. Pero si ya has subido tu commit a un repositorio remoto, se recomienda que no uses git reset, ya que reescribe el historial de commits. Esto puede hacer que trabajar en un repositorio con otros desarrolladores y mantener un historial consistente de commits sea muy difícil.

Solución: Restaurar a la última versión remota

git pull origin YOUR_BRANCH_NAME

• fuente

git revert #

En su lugar es mejor usar git revert, deshace los cambios realizados por un commit anterior creando un commit completamente nuevo, todo esto sin alterar el historial de commits.

Ejemplo:

17d793b (HEAD -> main) tercero.html
c97d996 nosotros.html
3f81f17 primer commmit

git revert 3f81f17

Ventajas

• Revertir presenta dos ventajas importantes con respecto a restablecer. En primer lugar, no cambia el historial del proyecto, lo que la convierte en una operación "segura" para las confirmaciones que ya se han publicado en un repositorio compartido.
• En segundo lugar, el comando git revert puede dirigirse a una sola confirmación en un punto arbitrario del historial, mientras que git reset solo puede volver hacia atrás desde la confirmación actual. Por ejemplo, si quisieras deshacer una confirmación anterior mediante git reset, tendrías que eliminar todas las confirmaciones que se hubieran producido después de la confirmación a la que va destinada la acción, eliminarla y, acto seguido, volver a confirmar todas las confirmaciones posteriores.
• fuente

Ramas o branch #

Hasta el momento solo hemos trabajado en la rama "master" o "main" pero puede que necesitemos crear diferentes ramas para los seguimientos de git.

git switch -c nombreRama

git switch nombreRama

git log --oneline --graph --all

// Crea una nueva rama
git branch nombreRama

// Nos muestra en que rama estamos
git branch

// Nos movemos a la nueva rama
git checkout nombreRama

// Nos muestra visualmente las ramas
git log --oneline --graph --all

git push --set-upstream origin nombreRama

git merge #

Podemos unir una rama con la nueva, para eso tenemos que estar en la rama para ejecutar el siguiente comando:

Tenemos que estar en la rama que está esperando los cambios (los nuevos cambios):

git merge nombreRama

git log --oneline --graph --all

// Eliminar una rama
git branch -d nombreRama

Conflictos #

Puedes utilizar las herramientas de VSCode o bien hacer los cambios manualmente en el archivo. Lo importante es hacer un nuevo commit al finalizar.

git add .
git commit -m "solucion de conflicto"

Tags #

Con los tags podemos hacer versiones de nuestro proyecto.

// Crear un tags
git tag versionAlpha -m "versión alpha"

// Listar tags
git tag

// Borrar tags
git tag -d nombreTags

// Hacer una versión en un commit anterior ej: f52f3da
git tag -a nombreTag f52f3da -m "version alpha"

// Mostrar información del tag
git show nombreTag

GITHUB: Subir los tags #

Por defecto si creaste un proyecto con diferentes versiones no subirá los tags, para eso tenemos el siguiente comando.

git push --tags

Push #

Al ejecutar el comando git push estaremos subiendo todos los cambios locales al servidor remoto de github, ten en cuenta que tienes que estar enlazado con tu repositorio, para eso puedes utilizar git remote -v luego ejecuta:

git push

Pull #

Cuando realizamos cambios directamente en github pero no de forma local, es esencial realizar un pull, donde descargaremos los cambios realizados para seguir trabajando normalmente.
Es importante estar enlazados remotamente, puedes verificar con: git remote -v, luego ejecuta:

git pull

Git Stash #

• fuente

El comando git stash nos permite guardar temporalmente los cambios que no están listos para ser confirmados. Esto es útil cuando necesitas cambiar de rama para trabajar en algo más urgente, pero no quieres hacer un commit de tus cambios actuales.

Guardamos los cambios

git stash

Listamos los cambios guardados

git stash list

Aplicamos los cambios guardados

git stash apply

Borramos los cambios guardados (stash@{0} es el identificador del cambio guardado)

git stash drop stash@{0}

Aplicamos y borramos los cambios guardados

git stash pop

Nombres de las ramas #

En un entorno de desarrollo de software en una empresa, las ramas que se crean pueden variar según las políticas de desarrollo específicas de cada empresa, así como también dependen del flujo de trabajo y las necesidades del proyecto en particular. Sin embargo, hay algunas ramas comunes que se suelen utilizar en muchos casos. Aquí hay algunas de las principales ramas que se pueden encontrar en un repositorio de Git en una empresa:

• main: Esta es la rama principal del proyecto. Contiene el código estable y funcional que está listo para ser desplegado en producción. Todos los cambios importantes y completados se fusionan en esta rama después de una revisión adecuada.
• develop: También conocida como rama de desarrollo, esta rama contiene el código en desarrollo para la próxima versión del software. Es donde se fusionan los cambios de las ramas de características y se prueban en conjunto antes de ser fusionados en la rama principal.
• feature: Se utilizan ramas de características para desarrollar nuevas funcionalidades o características. Cada vez que un desarrollador comienza a trabajar en una nueva característica, generalmente crea una rama de características a partir de la rama de desarrollo. Una vez que la característica está completa y ha sido revisada, se fusiona de nuevo en la rama de desarrollo.
• hotfix: Esta rama se utiliza para corregir problemas críticos en producción. Si se descubre un error que necesita ser solucionado de inmediato, se crea una rama de hotfix a partir de la rama principal (main o master), se realizan las correcciones necesarias y luego se fusiona tanto en la rama principal como en la rama de desarrollo.
• release: Se utiliza para preparar una nueva versión del software para su lanzamiento. Se crean ramas de lanzamiento a partir de la rama de desarrollo y se realizan las pruebas finales y los ajustes necesarios antes de fusionar en la rama principal y etiquetar la versión.

Estas son algunas de las ramas comunes que se pueden encontrar en un flujo de trabajo típico de Git en una empresa, pero es importante recordar que las prácticas de desarrollo pueden variar entre diferentes equipos y organizaciones. Adaptar el flujo de trabajo y las ramas específicas a las necesidades y requisitos del proyecto es clave para el éxito del desarrollo de software en cualquier empresa.

GitFlow #

• fuente

Gitflow es un flujo de trabajo de Git que se centra en el uso de ramas para gestionar las diferentes fases del desarrollo de software. Fue creado por Vincent Driessen en 2010 y se ha convertido en uno de los flujos de trabajo más populares para el desarrollo de software con Git.

Git Rebase #

• fuente

git rebase es un comando en Git que se utiliza para reorganizar la historia de los commits en una rama. Básicamente, toma todos los commits de una rama y los aplica sobre otra rama, generalmente sobre la rama en la que actualmente te encuentras.

Aquí un pequeño ejemplo:

git switch -c mi_rama
# Realizar cambios en los archivos
git add .
git commit -m "Mi mensaje de commit"

# Cambiar a la rama principal
git switch main
# Realizar cambios en los archivos
git add .
git commit -m "Mi mensaje de commit"

# Vuelve a la rama mi_rama
git switch mi_rama
# 👀 Reorganiza la historia de los commits
git rebase main # 👈🏽 Aquí estmos ocupando rebase

# Fusiona la rama mi_rama con la rama main
git switch main
git merge mi_rama

# Elimina la rama mi_rama
git branch -d mi_rama

Fork #

En GitHub, un "fork" es una copia de un repositorio que se crea en tu propia cuenta de GitHub. Esto te permite colaborar en proyectos de código abierto o hacer modificaciones en un proyecto existente sin afectar directamente al repositorio original.

¿Cómo hacer un pull al repositorio original? #

Cuando realizas un fork de un repositorio en GitHub y clonas tu repositorio forked localmente, el repositorio remoto configurado por defecto apunta a tu fork en GitHub. Por lo tanto, al ejecutar git pull, estás obteniendo los cambios que has realizado en tu repositorio forked localmente.

Para traer los cambios del repositorio original o base (desde el cual hiciste el fork), debes agregar un nuevo control remoto a tu repositorio local que apunte al repositorio original. Por lo general, este control remoto se llama "upstream". Aquí hay una serie de pasos que puedes seguir:

Agregar el repositorio original como un control remoto de tu repositorio local:

git remote add upstream <URL_del_repositorio_original>

Verificar que el nuevo control remoto se haya agregado correctamente:

git remote -v

Esto debería mostrar los URLs de los remotos "origin" (tu fork) y "upstream" (el repositorio original).

Para traer los cambios del repositorio original, primero debes asegurarte de estar en tu rama local principal (generalmente main o master):

git switch main

Luego, puedes obtener los cambios del repositorio original utilizando el comando git pull, especificando el remoto y la rama:

git pull upstream main

Esto traerá los cambios del repositorio original a tu rama principal local. Ahora, puedes combinar estos cambios en tu rama de desarrollo local o realizar cualquier otra acción necesaria.

Es importante tener en cuenta que debes sincronizar los cambios del repositorio original con tu fork periódicamente para mantener tu fork actualizado con los cambios más recientes.