Skip to content

GIT básico

[Actualizado a 22 de septiembre de 2026]

Lectura OBLIGATORIA => blog de Diego Martín.

Y en modo vídeo:

  1. Introducción a GIT por TodoCode
  2. Curso completo - Makigas

Resumen de zonas:

resumen git

Para crear un README en texto plano, pero con un formato agradable y convertible recurriremos al formato Markdown (Fazt Code - Markdown )

Ejercicio básico:

  1. Crear un repo con README.md conectado con GitHub.
  2. Añadir colaborador (profe @luiscastelar).
  3. El README.md contendrá vuestro nombre y email coorporativo.
  4. Clonar repositorio en otra ubicación y realizar una captura. Añadirla (integrada) al READMe.md.
  5. Crear un archivo de credenciales (nombre de usuario y contraseña) denominado .env.
  6. Crear archivo .gitignore con el contenido: *.env

Aplicaciones auxiliares: GitFiend o GitG como apoyo visual a git bash. También Git Extensions como plug-in de VS.

Conectando nuevos equipos

Nuevo repositorio

Cuando queramos conectar nuevos equipos, p.e. el de casa, al repositorio BARE (central) deberemos:

  1. Tener acceso al repositorio BARE mediante pares de llaves público/privadas, o por token[^1].
  2. Obtener la dirección del repositorio BARE al que queremos conectar. Ésta debe ser del tipo git@github.com:luiscastelar/pruebasDAW1.git. Ésta dirección tiene 3 partes:
  3. git@github.com -> el servidor al que nos estamos conectando [^2].
  4. luiscastelar -> vuestro nombre de usuario en github (o el servidor al que os conectéis).
  5. pruebasDAW1.git -> el repositorio al que os estáis conectando.
  6. Clonar el repositorio sobre el directorio que deseemos con git clone git@github.com:luiscastelar/pruebasDAW1.git {{NOMBRE DEL DIRECTORIO}}.

A repositorio ya existente

También podemos conectar un repositorio local ya creado anteriormente y con contenido con el comando git remote add origin git@github.com:luiscastelar/pruebasDAW1.git, y posteriormente sincronizar sus contenidos con:

git pull origin main
git push -u origin main

Con el primer comando descargamos el contenido remoto y con el segundo subimos el contenido local y establecemos origin como push por defecto.

A menudo se producirán conflictos en el git pull que deberemos resolver a mano.

Revisión de la historia

  • Detallado: git log
  • Resumido en una línea: git log --pretty=oneline
  • Con más datos: git log --pretty=format:"%h - %an, %ar : %s"
  • En árbol: git log --graph

Y por supuesto combinados: git log --pretty=oneline --graph

Ver cambios entre versiones

git diff <commit-id-1> <commit-id-2> -- file-to-check

Pudiendo ser hash de commit, etiquetas o nombre de ramas.

Revertir cambios: revertir, restaurar y resetear

git reset vs git revert vs git restore

Hay tres comandos con nombres similares: git reset, git restore y git revert.

  • git-revert[1] es acerca de hacer un nuevo commit que revierta los cambios hechos por otros commits. Comando recomendado ya que evita problemas en grupos de trabajo.

  • git-restore[1] es acerca de restaurar ficheros en el árbol de trabajo de ya sea el índice u otro commit. Este comando no actualiza tu rama. El comando también puede usarse para restaurar ficheros en el índice de otro commit.

  • git-reset[1] es acerca de actualizar tu rama, moviendo la punta con el fin de agregar o eliminar commits de la rama. Esta operación cambia el historial de commits. Debemos evitar su uso.

Merge y rebase

¿Qué ocurre cuando trabajamos con ramas o hemos realizado cambios desde 2 equipos distintos? \ Ramas

Pues que tenemos que unir los caminos. Tenemos 2 opciones: merge y rebase.

  • git merge crea un commit MERGE de unión de ambas ramas.
  • git rebase crea un commit REBASE que contiene los commits de la línea temporal alternativa y elimina la elimina. Como si nunca hubiera existido, pero con el mismo resultado que el merge.

Ventaja: Visualmente más sencillo ya que el historial aparece lineal.

Inconveniente: Los creadores de los commits que desaparecen pierden el seguimiento de sus cambios por los HASH. => SÓLO REALIZAR EN REPOSITORIOS UNIPERSONALES o nunca.

merge-rebase

cherry-pick

Nooooo:

PRÁCTICA (voluntaria)

Haz sólo lo que no tengas ya en el ejercicio anterior:

  1. Crea una cuenta en github (con el email corporativo).
  2. Crea un repositorio privado (vacío).
  3. Sigue los pasos que te proporciona para crear un git local o subir uno existente.
  4. Crea un README.md con:
  5. Autor del repositorio
  6. eMail de contacto (corporativo)
  7. Crea un directorio para la UT1 con un README.md donde documentes esta práctica.
  8. En otra carpeta, clona tu repositorio remoto.
  9. Captura de pantalla.
  10. Súbela a ./img
  11. Enlázala al README de la práctica.
  12. Crea un archivo “a.txt” con 3 líneas y sincroniza con el repositorio remoto.
  13. Modifica la primera línea del archivo en la web y la tercera en local con contenidos distintos e intenta sincronizarlos. Captura el conflicto y añádelo a la documentación.
  14. Busca la estrategia de solucionar el conflicto y realiza un merge.
  15. Mediante gitfiend o gitg captura la línea de tiempo.
  16. Regresa al punto 7 (en el tiempo) y muestra el contenido del archivo a.txt mediante una captura.
  17. Vuelve al HEAD y documentalo todo.

Cheat-sheat

Resumen de comandos

== Trabajo de 2º ==

Trabajando con ramas:

Creación y fusión de ramas

Sincronización de ramas

En ocasiones aparecen nuevas ramas en remoto que debemos crear en local para poder descargar las actualizaciones. ¿Lo más sencillo? 

for remote in `git branch -r | grep -v /HEAD`; do git checkout --track $remote ; done`
git pull -a

Gestión de ramas

Traer commits a la rama RAMA

Cuando en la rama dev hemos realizado commits interesantes puede ser de gran relevancia poder traérnoslos a la rama main.

Para ello sólo necesitamos conocer su hash (1) y, desde la rama main (a la que lo queremos llevar) deberemos escribir git cherry-pick HASH.

(1) Para capturar su hash, nos ubicaremos en la rama dev con git checkout dev y veremos el historial de commits con git log. Ésto nos arrojará el hash de cada commit, además de la descripción, autor y marca temporal.

Jugando con ramas

Ejercicios

Git ramas

Mover ramas

Resulta que me he liado y he creado una rama main en remoto y en local no leí y deje por defecto la rama master. ¿Qué puedo hacer?

Tenemos varias opciones, pero voy a simplificarlas en 2:

  1. Renombrar la rama remota de main a master y seguir las indicaciones que nos proporciona github: bash git branch -m main master git fetch origin git branch -u origin/master master git remote set-head origin -a
  2. Clonar la rama main en un nuevo repositorio remoto, aplicar los cambios en local a mano (sugiero la aplicación Meld) y subir los cambios.

Forks

Pull request

Preguntas que todo programador debería conocer

Eso

Tarea paso a paso

Git es la herramienta estándar para el control de versiones. Este tutorial cubre desde la configuración inicial hasta un flujo de trabajo colaborativo por parejas (pair programming o feature-branch workflow).

1. Configuración inicial de Git: Requisito único antes de empezar a crear repositorios.

Configura tu identidad global para que cada commit lleve tus datos.

git config --global user.name "Tu Nombre"
git config --global user.email "tu_email@ejemplo.com"
git config --global init.defaultBranch main

2. Crear y preparar el repositorio local: Inicialización y primer flujo de trabajo.

Crea una carpeta de proyecto e inicia Git.

mkdir proyecto-colaborativo
cd proyecto-colaborativo
git init

Crea un archivo, añádelo al área de preparación (staging) y confirma los cambios (commit):

echo "# Proyecto Colaborativo" > README.md
git add README.md
git commit -m "feat: inicializar proyecto con README"

3. Conectar con un repositorio remoto (GitHub/GitLab): Preparación para el trabajo colaborativo.

Crea un repositorio vacío en la plataforma (sin README ni .gitignore) y vincúlalo a tu máquina local:

git remote add origin https://github.com/tu-usuario/proyecto-colaborativo.git
git branch -M main
git push -u origin main

4. Estrategia de ramas (Branching): Aislación de características para desarrollo seguro.

Nunca trabajes directamente sobre main. Crea una rama para una nueva funcionalidad (feature):

# Crear y cambiar a una nueva rama
git checkout -b feature/login

# (Alternativa moderna en Git 2.23+)
# git switch -c feature/login

Haz cambios en esta rama, prepáralos y guárdalos:

echo "function login() {}" > login.js
git add login.js
git commit -m "feat: agregar estructura base de login"

Sube la rama al servidor remoto:

git push -u origin feature/login

5. Flujo colaborativo por parejas (Pair Programming): Simulación entre Desarrollador A y Desarrollador B.

Desarrollador B (Clonar y colaborar): Obtiene el proyecto existente en su máquina:

git clone https://github.com/tu-usuario/proyecto-colaborativo.git
cd proyecto-colaborativo

Crea su propia rama de trabajo:

git checkout -b feature/perfil-usuario
# ... hace cambios ...
git add .
git commit -m "feat: agregar vista de perfil"
git push -u origin feature/perfil-usuario

Revisión mediante Pull Request (PR):

  1. El Desarrollador B abre un Pull Request o Merge Request en la plataforma web desde feature/perfil-usuario hacia main.
  2. El Desarrollador A revisa el código, deja comentarios o lo aprueba, y hace clic en Merge.

6. Sincronización y gestión de conflictos: Mantener el código al día entre ambos desarrolladores.

Una vez que la rama feature/perfil-usuario se fusionó en main, el Desarrollador A debe actualizar su entorno local:

git checkout main
git pull origin main

Si el Desarrollador A estaba trabajando en feature/login y necesita incluir los cambios recién traídos de main:

git checkout feature/login
git merge main

Resolver un conflicto: Si ambos modificaron la misma línea del mismo archivo, Git detendrá el merge y marcará el archivo:

<<<<<<< HEAD
console.log("Login versión A");
=======
console.log("Login versión B");
>>>>>>> main
  1. Edita el archivo manualmente borrando las marcas y dejando el código correcto.
  2. Marca el conflicto como resuelto y completa la fusión:
git add login.js
git commit -m "fix: resolver conflicto de integración con main"
git push origin feature/login

Comandos rápidos de consulta cotidiana

  • git status: Muestra el estado del área de trabajo y staging.
  • git log --oneline --graph --all: Historial visual y compacto de commits y ramas.
  • git branch -a: Lista todas las ramas (locales y remotas).
  • git branch -d nombre-rama: Elimina una rama local integrada.
  • git fetch --all --prune: Actualiza las referencias remotas borrando ramas eliminadas en el servidor.

Hooks

Algo general: Hooks - Jeremy Holcombe

Pre-commit

Como estamos trabajando sobre Java, utilizaremos un pre-commit inicial para verificar el estilo de código.

Si estuviéramos en otros lenguajes, especialmente aquellos sin tipado fuerte, podríamos verificar algunas cosas sobre tipos y analizadores sintácticos en lenguajes no compilados.

  1. Instalación
  2. Configuración de git para utilizar el analizador
  3. Ajustes de estilos. Podemos querer adaptarlo a nuestra necesidades (de empresa).
  4. Probarlo: bash git commit -m"style fix google" Comenzando auditoría... Auditoría concluida. [main e0eaeed] style fix google 1 file changed, 128 insertions(+), 105 deletions(-) rewrite Palindromos.java (96%)

Podemos ver en las líneas 2 y 3 que realiza la auditoría de código y la pasa sin warnings.

En este punto, podría ser interesante plantearnos si deberá pasar los test antes de los commits, después o antes del push.

Post-receive

Utilizado para CI/CD... lo veremos ampliamente más adelante.

Seguridad

Borrando archivos que NO debieron publicarse.

ADVERTENCIA: Este procedimiendo debe reescribir todo el historial de GIT por lo que debes avisar a todo el equipo.

Para borrar completamente la trazabilidad de un archivo de todos los commits pasados (historial), debes reescribir la historia de Git.

Opción 1: Método nativo rápido (git filter-branch)

No requiere instalar nada adicional. Ejecuta el siguiente comando especificando la ruta de tu archivo:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch RUTA/DE/TU/ARCHIVO" --prune-empty --tag-name-filter cat -- --all
  • Verificación: Corre git log --all -- RUTA/DE/TU/ARCHIVO. No debería aparecer ningún commit en el resultado. Tu archivo físico seguirá intacto en la carpeta local.

Opción 2: La herramienta recomendada (git-filter-repo o BFG)

Git considera filter-branch una herramienta antigua y lenta. La alternativa oficial actual es git-filter-repo.

Si la tienes instalada (p. ej. pip install git-filter-repo o brew install git-filter-repo), solo ejecutas:

git filter-repo --path RUTA/DE/TU/ARCHIVO --invert-paths

Paso final: Actualizar el servidor remoto

Una vez eliminado del historial local, debes forzar la actualización en GitHub/GitLab:

git push origin --force --all

Referencias:

Notas al pie

[^1]: Es un sistema de acceso a nuestro repositorio que se genera un token con los permisos necesarios a el repositorio adecuado y con fecha de caducidad, lo cual otorga bastante seguridad. [Información sobre acceso por token]. [^2]: Puede haber otros servidores interesantes, p.e. gitlab, gitbucket, o el vuestro privado.