Saltar a contenido

1.3.-Git Github

1.3. Git y GitHub

Idea principal

Git registra la evolución de los archivos de un proyecto y permite trabajar con cambios aislados y recuperables. GitHub aloja repositorios Git y añade herramientas para compartir el trabajo, revisarlo y organizar la colaboración.

En el apartado anterior has visto cómo documentar un proyecto. Para que esa documentación y el código puedan evolucionar de forma coordinada, hace falta registrar sus cambios y saber quién los ha realizado. Sin control de versiones, sería fácil sobrescribir trabajo ajeno, perder una versión que funcionaba o no entender por qué se tomó una decisión.

En este tema aprenderás a utilizar Git para guardar cambios de forma local y a relacionarlo con GitHub para compartirlos y revisarlos. El objetivo no es memorizar una lista de comandos, sino entender qué información guarda cada paso y elegir un flujo de trabajo seguro para un proyecto web.

Este contenido contribuye al RA 6 del módulo y trabaja los criterios de evaluación CE 6.d, CE 6.e, CE 6.f y CE 6.g. La tabla recoge literalmente los descriptores de la normativa:

Código Descripción
RA 6 Elabora la documentación de la aplicación web evaluando y seleccionando herramientas de generación de documentación, control de versiones y de integración continua.
CE 6.d Se han utilizado herramientas colaborativas para la elaboración y mantenimiento de la documentación.
CE 6.e Se ha instalado, configurado y utilizado un sistema de control de versiones.
CE 6.f Se ha garantizado la accesibilidad y seguridad de la información y código almacenada por el sistema de control de versiones.
CE 6.g Se ha documentado la instalación, configuración y uso del sistema de control de versiones utilizado.

El tema te permitirá reconocer el funcionamiento de Git, preparar cambios, crear ramas y colaborar mediante GitHub. La práctica asociada te ayudará a aplicar estas operaciones en un proyecto real. La automatización con GitHub Actions se desarrolla en el apartado siguiente.

Qué deberías saber al terminar

Al acabar este tema deberías poder:

  • explicar la diferencia entre Git, un repositorio local y GitHub;
  • configurar Git y describir el ciclo de trabajo modificar → preparar → confirmar;
  • consultar el estado y el historial, crear commits y recuperar cambios con criterio;
  • crear ramas, integrarlas y explicar cómo se resuelven conflictos;
  • distinguir fetch, pull y push, y describir el papel de las pull requests y los forks;
  • reconocer Git Flow, GitHub Flow y Trunk Based Development, y valorar cuándo encaja cada uno.

Mapa del tema

Seguiremos esta secuencia:

  1. qué problema resuelve el control de versiones y qué aportan Git y GitHub;
  2. cómo se organizan los cambios en un repositorio Git;
  3. cómo configurar Git y utilizar los comandos esenciales;
  4. cómo revisar el historial, recuperar cambios y trabajar con ramas;
  5. cómo colaborar mediante repositorios remotos, GitHub y distintos flujos de trabajo.

1. Control de versiones: Git y GitHub

Control de versiones

Sistema que registra la evolución de uno o varios archivos y permite consultar cambios, comparar versiones y recuperar estados anteriores.

Así se puede coordinar el trabajo de varias personas sobre código, documentación, configuración y otros ficheros del proyecto.

Git es un sistema de control de versiones distribuido. Linus Torvalds lo creó en 2005 para facilitar el desarrollo del núcleo Linux. Cada clon normal de un repositorio contiene una copia local del proyecto y de su historial, por lo que muchas operaciones —como consultar el historial o crear una rama— se pueden realizar sin conexión. Una copia local no sustituye por sí sola a una copia de seguridad: para compartir o preservar cambios ante la pérdida del equipo, hay que sincronizarlos con un remoto y mantener una estrategia de copias adecuada.

GitHub es una plataforma que aloja repositorios Git y ofrece servicios de colaboración, como revisión de código, seguimiento de tareas y automatización. Git también se puede utilizar con otros servicios —por ejemplo, GitLab o Bitbucket— o sin ningún servicio remoto. Por tanto, Git y GitHub están relacionados, pero no son lo mismo.

Elemento Qué es Ejemplo de uso
Git Sistema de control de versiones que se ejecuta en el equipo y gestiona el historial. Registrar el cambio de una página web en un commit.
Repositorio local Proyecto y datos de Git almacenados en el equipo. Trabajar en una rama aunque no haya conexión.
Repositorio remoto Repositorio alojado en otro servidor y accesible mediante una URL. Compartir commits con el equipo desde GitHub.
GitHub Servicio web que aloja repositorios Git y herramientas de colaboración. Proponer cambios mediante una pull request.

Un commit todavía no está en GitHub

git commit guarda una versión en el repositorio local. Para compartirla con el remoto se utiliza git push. Del mismo modo, tener un repositorio en GitHub no significa que los cambios del equipo se hayan descargado: hay que traerlos con git fetch o git pull.

2. Repositorio, commits y estados de los archivos

Un repositorio es el proyecto gestionado por Git: contiene los archivos de trabajo y los datos necesarios para registrar su historial. Al inicializarlo, Git crea una carpeta interna llamada .git. No conviene editar manualmente su contenido.

Estos conceptos ayudan a interpretar lo que muestra Git:

Concepto Para qué sirve Ejemplo
Commit Registra una instantánea coherente del contenido preparado, junto con autoría, fecha y mensaje. Añade validación del formulario
Rama (branch) Mantiene una línea de trabajo identificada por un nombre que apunta a un commit. feature/filtro-productos
Área de preparación (staging area o index) Selecciona qué cambios entrarán en el siguiente commit. Preparar la plantilla, pero no un fichero temporal.
Directorio de trabajo (working tree) Archivos visibles en los que editas el proyecto. Modificar index.html en el editor.
HEAD Indica la posición actual en el historial; normalmente apunta a la rama activa y, a través de ella, a su último commit. Estar en main antes de crear un commit.
Etiqueta (tag) Da un nombre estable a un commit importante, a menudo una versión publicada. v1.0.0

Cada commit tiene un identificador calculado a partir de su contenido y sus metadatos. En repositorios Git que usan el formato de objetos SHA-1, suele mostrarse como 40 caracteres hexadecimales; Git también admite repositorios con formato SHA-256. El identificador permite referirse a una revisión, pero no reemplaza las medidas de control de acceso ni protege el repositorio frente a un uso no autorizado. Git lo utiliza para identificar objetos y detectar cambios en su contenido; no lo confundas con un mecanismo de permisos.

El ciclo local pasa por tres espacios: directorio de trabajo, área de preparación e historial del repositorio. git add prepara cambios; git commit registra lo que está preparado. Después, git push puede compartir los commits con un repositorio remoto.

flowchart LR
  A["Directorio de trabajo<br/>editar archivos"] -->|git add| B["Área de preparación<br/>seleccionar cambios"]
  B -->|git commit| C["Repositorio local<br/>registrar un commit"]
  C -->|git push| D["Repositorio remoto<br/>compartir commits"]
  D -->|fetch| E["Referencias remotas locales<br/>cambios descargados"]
  E -->|merge| C
  D -->|pull| C

En git status, los archivos pueden aparecer como no rastreados, modificados o preparados. Un archivo nuevo es no rastreado (untracked) hasta que Git empieza a seguirlo. Un archivo seguido puede estar modificado (modified) si ha cambiado en el directorio de trabajo, o preparado (staged) si has seleccionado una versión de sus cambios para el próximo commit. El estado confirmado (committed) indica que los cambios ya están registrados en el historial local. Un mismo archivo puede tener cambios preparados y otros aún sin preparar si lo editas de nuevo después de git add.

Una modificación en dos tiempos

Si editas README.md y ejecutas git add README.md, Git prepara la versión que existe en ese instante. Si vuelves a editar el fichero antes del commit, el cambio nuevo queda fuera de esa selección hasta que lo prepares otra vez. Por eso es importante comprobar el estado y revisar el contenido preparado antes de confirmar.

3. Configuración y comandos esenciales

3.1. Instalar Git

Git es un programa que se instala en el equipo; crear una cuenta de GitHub no lo instala ni sustituye sus comandos locales. Descarga el instalador adecuado para tu sistema operativo desde la página oficial de descargas de Git o utiliza el gestor de paquetes de tu distribución. Después, abre una terminal nueva y comprueba la instalación:

git --version

El comando muestra la versión disponible. Si el sistema no reconoce git, comprueba que la instalación haya terminado y que el programa esté disponible en la variable PATH.

3.2. Configurar la identidad

Antes de crear commits, configura el nombre y el correo que aparecerán en su autoría. --global guarda estos valores para todos los repositorios de tu cuenta del sistema; si un proyecto necesita otros datos, puedes establecerlos sin --global desde ese repositorio.

git config --global user.name "Tu Nombre"
git config --global user.email "tu.email@ejemplo.com"

# Opcional: abre Visual Studio Code para editar mensajes de commit
git config --global core.editor "code --wait"

# Opcional: muestra la salida de Git en color
git config --global color.ui auto

Utiliza una dirección de correo apropiada para los proyectos que publiques. Si no quieres mostrar tu correo personal en GitHub, consulta la opción de dirección noreply de tu cuenta y configúrala según las instrucciones de GitHub.

Hay dos formas habituales de obtener un repositorio:

  • git init crea un repositorio en una carpeta que ya tienes. Con versiones actuales de Git puedes indicar la rama inicial con git init -b main.

  • git clone <URL> descarga un repositorio remoto y crea una carpeta de trabajo para él. Por ejemplo:

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

Si el proyecto no existe todavía en remoto, puedes inicializarlo en una carpeta que contenga, por ejemplo, un README.md. Después, prepara y registra el primer commit, conecta el remoto y comparte la rama:

# Ejecuta estos comandos dentro de la carpeta del proyecto
git init -b main
git status
git add README.md
git diff --staged
git commit -m "Añade la presentación del proyecto"

# Sustituye la URL por la del repositorio remoto que hayas creado
git remote add origin https://github.com/usuario/mi-proyecto.git
git remote -v
git push -u origin main

origin es un nombre convencional para el remoto principal; no es una palabra reservada. La opción -u establece una relación de seguimiento para que Git recuerde el remoto y la rama al hacer posteriores git push y git pull. Cuando clonas, Git configura origin automáticamente. No inicialices a la vez el mismo proyecto con historiales distintos en GitHub y en tu equipo: es más sencillo crear el remoto vacío y publicar el primer commit local, o clonar el remoto antes de empezar.

Estos son los comandos que utilizarás con más frecuencia:

Comando Qué muestra o hace
git status Estado de los archivos y de la rama actual.
git add archivo Prepara los cambios de un archivo para el siguiente commit.
git add . Prepara los cambios del directorio actual y sus subdirectorios; úsalo tras revisar qué incluye.
git diff Diferencias entre el directorio de trabajo y el área de preparación.
git diff --staged Diferencias que están preparadas respecto al último commit. También se admite --cached.
git diff <commit-a> <commit-b> Diferencias entre dos commits.
git commit -m "mensaje" Registra en el historial los cambios preparados.
git log / git log --oneline Historial detallado o resumido de commits, respectivamente.
git show <commit> Detalles y cambios de un commit concreto; HEAD identifica la posición actual.
git blame archivo Muestra, línea a línea, el último commit que modificó cada línea.

Un mensaje útil permite entender el propósito del cambio sin abrir cada fichero. Escribe un asunto breve y descriptivo, normalmente en imperativo —por ejemplo, «Añade validación al formulario»— y añade un cuerpo si hace falta explicar el contexto. Algunos equipos recomiendan limitar la primera línea a unos 50 caracteres; es una convención útil, no una regla de Git.

4. Historial, recuperación y ramas

Git guarda commits locales y permite comparar versiones para investigar o recuperar cambios. No todas las operaciones para «deshacer» tienen el mismo efecto: antes de ejecutarlas, comprueba si el commit ya se ha compartido y qué archivos perderías.

4.1. Deshacer con criterio y excluir archivos

  • git revert <commit> crea un commit nuevo que invierte los cambios del commit indicado. Conserva el historial anterior y suele ser la opción más segura para deshacer cambios que ya se han publicado.
  • git commit --amend sustituye el commit más reciente por otro. Puede corregir su mensaje o incorporar cambios que acabas de preparar, pero cambia el identificador del commit; úsalo solo si todavía no lo has compartido con otras personas.
  • git reset --soft <commit> mueve la rama actual a otro commit, pero deja los cambios posteriores preparados. Puede servir para reorganizar commits locales que aún no se han compartido.
  • git reset --hard HEAD restablece el directorio de trabajo y el área de preparación al commit actual. Descarta cambios rastreados que no estén confirmados y puede causar pérdida de trabajo; no lo ejecutes como una forma rutinaria de «arreglar» un estado confuso.
  • git rm archivo elimina un archivo del directorio de trabajo y prepara su eliminación. git rm --cached archivo deja el archivo local, pero lo saca del seguimiento de Git.

Para que Git ignore ficheros generados, temporales o locales, añade patrones a un archivo .gitignore situado en el proyecto. Por ejemplo:

# Registros y archivos temporales
*.log
*~

# Dependencias instaladas y ficheros compilados
node_modules/
*.class

# Ignorar los archivos .a, excepto lib.a
*.a
!lib.a

# Configuración local que puede contener credenciales
.env

.gitignore evita que Git proponga incorporar archivos que todavía no sigue; no deja de seguir automáticamente un archivo que ya se había confirmado. Si una credencial se ha publicado, quitarla del fichero o añadirlo a .gitignore no basta: hay que revocar o rotar la credencial y tratar la exposición en el historial.

4.2. Ramas y fusión

Una rama es una referencia ligera a una línea de commits, no una copia completa del proyecto. Permite desarrollar una funcionalidad, corregir un error o experimentar sin incorporar ese trabajo directamente a la rama principal, que suele llamarse main (en repositorios antiguos, master).

# Crear una rama y cambiarse a ella
git switch -c feature/filtro-productos

# Consultar las ramas locales y volver a la principal
git branch
git switch main

# Integrar la rama en la rama actual
git merge feature/filtro-productos

Los comandos git checkout -b <rama> y git checkout <rama> también se usan para crear y cambiar de rama. En versiones actuales de Git, git switch suele ser más claro para cambiar de rama, mientras que git checkout conserva usos adicionales.

git merge integra en la rama actual los cambios de otra rama. Git puede realizar la fusión automáticamente; si no puede combinar cambios compatibles, marca un conflicto para que decidas cómo integrar el contenido. En el archivo aparecerán marcas parecidas a estas:

Marca Qué indica
<<<<<<< HEAD Inicio del contenido de la rama actual.
======= Separación entre las dos propuestas.
>>>>>>> feature/filtro-productos Fin del contenido de la otra rama.

Lee ambas versiones, edita el archivo para dejar el resultado correcto y elimina las marcas. A continuación, prepara el archivo resuelto con git add y termina la fusión con git commit si Git lo solicita. Si decides no continuar, puedes usar git merge --abort antes de completar la fusión. Un conflicto no significa que Git haya perdido los cambios: indica que necesita una decisión humana.

4.3. Rebase, etiquetas y versiones

git rebase <rama> vuelve a aplicar los commits de la rama actual sobre la punta de otra rama. Puede facilitar un historial lineal, pero reescribe los commits afectados y, por ello, sus identificadores. Utilízalo para organizar trabajo local que todavía no comparte el equipo; evita reescribir commits sobre los que otras personas ya han basado su trabajo. Si aparecen conflictos, resuélvelos y continúa con git rebase --continue, o cancela la operación con git rebase --abort.

Las etiquetas (tags) señalan commits importantes, a menudo versiones de entrega:

# Etiqueta anotada: incluye autoría, fecha y mensaje
git tag -a v1.0.0 -m "Publica la versión 1.0.0"

# Consultar etiquetas y detalles
git tag
git show v1.0.0

# Compartir las etiquetas con el remoto
git push origin --tags

Una etiqueta ligera es un nombre que apunta a un commit; una etiqueta anotada guarda además metadatos y un mensaje, por lo que suele preferirse para marcar versiones. Las etiquetas locales no se comparten al subir una rama, salvo que se incluyan explícitamente.

5. Colaboración con remotos, GitHub y flujos de trabajo

Un remoto es un nombre asociado a la URL de otro repositorio. Para consultarlo o añadir uno, se utilizan git remote -v y git remote add:

git remote -v

# Ejecuta este comando solo si todavía no tienes configurado origin
git remote add origin https://github.com/usuario/mi-proyecto.git

Las operaciones de sincronización tienen propósitos diferentes:

Comando Función Qué ocurre en tu rama actual
git fetch origin Descarga referencias y commits del remoto. No integra por sí solo los cambios en los archivos de la rama actual; puedes revisarlos antes.
git pull origin main Obtiene cambios e intenta integrarlos en la rama actual. Equivale, en el flujo habitual, a fetch seguido de una integración mediante merge o la estrategia configurada.
git push origin main Envía al remoto los commits locales de main. Comparte los commits; no envía cambios que no se hayan confirmado.

Antes de empezar una tarea, consulta el estado de tu rama y acuerda con el equipo cómo incorporar los cambios recientes. Un pull puede producir una fusión o un conflicto, así que conviene entender qué va a integrar en vez de repetir el comando sin revisar el resultado.

5.1. Pull requests y forks

GitHub añade funciones de colaboración sobre Git. Entre las más habituales están:

  • Pull requests: propuestas para integrar cambios de una rama o de un fork en otra rama. Permiten explicar el propósito, revisar diferencias, comentar líneas, ejecutar comprobaciones y decidir cuándo fusionar. Una PR es un espacio de revisión y conversación; no es un comando de Git.
  • Issues: registro de errores, tareas, preguntas y propuestas de mejora.
  • Hitos: Asigna responsables, etiquetas e hitos para organizar el seguimiento
  • Projects: tableros para organizar y seguir tareas.
  • Wiki: páginas colaborativas asociadas a un repositorio, si el proyecto las utiliza.
  • GitHub Actions: automatización de tareas del repositorio, como pruebas y despliegues; se desarrolla en el apartado siguiente.

Un flujo habitual de pull request es:

  1. Crear una rama de vida corta para un cambio concreto.
  2. Hacer commits comprensibles y probar el cambio.
  3. Enviar la rama a GitHub con git push -u origin nombre-rama.
  4. Abrir una PR hacia la rama de destino y explicar el objetivo, el contexto y las pruebas.
  5. Revisar la propuesta, responder a comentarios y corregir lo necesario.
  6. Fusionar la PR cuando se cumplan las comprobaciones y las reglas del proyecto.

Las PR pequeñas, con un objetivo claro y una descripción útil, suelen ser más fáciles de revisar. Antes de abrirla, comprueba tus propios cambios y evita mezclar tareas sin relación. El proyecto puede usar plantillas de PR, revisiones obligatorias o pruebas automáticas para hacer este proceso más consistente.

Un fork es una copia de un repositorio alojada en otra cuenta de GitHub. Se utiliza, por ejemplo, cuando no se tienen permisos para escribir en el proyecto original. El flujo habitual es:

  1. En GitHub, selecciona Fork en el repositorio original.
  2. Clona el fork que se ha creado en tu cuenta.
  3. Crea una rama local, realiza los cambios y confírmalos.
  4. Sube la rama a tu fork y abre una PR hacia el repositorio original.

Por ejemplo, si tu usuario es alumna y el repositorio se llama mi-proyecto, puedes clonar tu fork y publicar una rama de trabajo así:

git clone https://github.com/alumna/mi-proyecto.git
cd mi-proyecto
git switch -c feature/mejora

# Edita los archivos y confirma solo los cambios relacionados
git add archivo-modificado
git commit -m "Añade una mejora"
git push -u origin feature/mejora

Después, crea la PR desde feature/mejora de tu fork hacia la rama de destino del repositorio original. Si necesitas actualizar el fork con cambios nuevos del original, puedes configurar un segundo remoto —convencionalmente llamado upstream— y traer sus referencias con git fetch upstream antes de integrarlas en tu rama.

Acceso y seguridad del repositorio

En un repositorio público, cualquier persona puede consultar el contenido; en uno privado, el acceso depende de los permisos concedidos por el proyecto. Aplica el principio de mínimo privilegio, protege la rama principal con las revisiones y comprobaciones que necesite el equipo, y usa autenticación segura, por ejemplo mediante una clave SSH o un gestor de credenciales para HTTPS. La visibilidad privada no sustituye estas medidas. Nunca guardes contraseñas, tokens ni claves privadas en el historial. Si una credencial llega a publicarse, revócala o rótala de inmediato y sigue el procedimiento de respuesta del proyecto.

5.2. Flujos de trabajo con ramas

Un flujo de trabajo (workflow) define cómo se crean, revisan y fusionan las ramas de un equipo. No existe un modelo universal: la elección depende de la frecuencia de entrega, la organización de las versiones y la experiencia del equipo.

Git Flow propone ramas de larga duración y ramas temporales. Es una opción estructurada para proyectos con versiones y ciclos de entrega planificados:

  • main conserva las versiones publicadas y estables;
  • develop integra el trabajo destinado a una próxima versión y puede contener cambios aún no publicables;
  • feature/* desarrolla funcionalidades desde develop y vuelve a integrarse en ella;
  • release/* parte de develop para preparar una entrega y, tras estabilizarla, se integra en main y en develop;
  • hotfix/* parte de main para corregir con urgencia una versión publicada y se integra en las ramas que deban conservar la corrección.
Diagrama de ramas main, develop, feature, release y hotfix de Git Flow
Git Flow separa el desarrollo habitual, la preparación de entregas y las correcciones urgentes.

GitHub Flow es más simple y gira alrededor de una rama principal y ramas de vida corta. El equipo crea una rama para cada cambio a partir de main, abre una PR, revisa y prueba la propuesta y la integra en main cuando cumple los requisitos; se procura que main permanezca en estado desplegable. El despliegue puede automatizarse después de la integración, pero no ocurre por utilizar GitHub Flow: requiere configurar el proceso de entrega.

Diagrama de GitHub Flow con una rama de funcionalidad y una pull request hacia la rama principal
GitHub Flow utiliza ramas cortas y una pull request para revisar cada cambio antes de integrarlo.

Trunk Based Development integra cambios pequeños y frecuentes en una rama principal compartida, llamada trunk o main. El equipo puede integrar directamente o utilizar ramas de vida muy corta. Las pruebas automatizadas y la coordinación reducen el riesgo de introducir errores; las funcionalidades incompletas se pueden mantener ocultas mediante feature flags (interruptores que permiten activar u ocultar funcionalidades sin retirar su código).

La integración frecuente de código contribuye a la integración continua (CI). Para desplegarlo de forma continua (CD) también hay que automatizar y configurar la entrega; trabajar sobre main no activa por sí solo un despliegue.

Diagrama de Trunk Based Development con cambios pequeños que se integran frecuentemente en la rama principal
Trunk Based Development busca integrar cambios pequeños con frecuencia en la rama principal.
Flujo Organización característica Puede encajar cuando…
Git Flow Varias ramas de larga duración y ramas temporales para funcionalidades, entregas y correcciones urgentes. El proyecto mantiene versiones y ciclos de publicación planificados.
GitHub Flow Rama principal y ramas breves revisadas mediante PR. El equipo quiere un proceso sencillo de revisión e integración frecuente.
Trunk Based Development Integración muy frecuente en una rama principal; las ramas auxiliares, si se usan, duran poco. El equipo puede automatizar pruebas y reducir el tamaño de cada cambio.

El riesgo del trabajo directo sobre la rama principal no se resuelve eligiendo un nombre de flujo: hacen falta revisiones, pruebas, commits pequeños y comunicación. Acordad un modelo y aplicadlo de forma consistente.

5.3. Clientes gráficos

Git se puede utilizar desde la terminal o mediante clientes gráficos. Una interfaz ayuda a visualizar diferencias, ramas e historial, pero no cambia el funcionamiento de Git: es importante entender qué operación se va a ejecutar y comprobar su resultado.

  • Visual Studio Code incluye integración con Git. Extensiones como GitLens muestran información de autoría e historial; Git Graph permite visualizar commits y ramas; y hay extensiones que facilitan operaciones de Git Flow.
  • GitKraken ofrece una interfaz gráfica para ramas, fusiones, conflictos e historial, con integraciones con varios servicios de alojamiento.
  • GitHub Desktop, disponible para Windows y macOS, facilita las operaciones habituales con repositorios de GitHub, como crear ramas, preparar cambios, confirmar y abrir pull requests.

6. Buenas prácticas

Para que el historial ayude al equipo y no se convierta en una fuente de incertidumbre, conviene:

  • Comprobar el estado antes y después de cada operación: utiliza git status y revisa git diff o git diff --staged antes de crear un commit.
  • Preparar cambios de forma consciente: prefiere git add archivo cuando necesites controlar qué entra en el commit; antes de usar git add ., revisa qué archivos abarca.
  • Crear commits pequeños y coherentes: cada commit debería expresar un cambio comprensible y tener un mensaje claro, en imperativo cuando encaje con la convención del equipo.
  • Usar ramas enfocadas y de vida razonablemente corta: reduce el trabajo paralelo difícil de integrar y facilita revisar cada PR.
  • Sincronizar y revisar antes de compartir: comprueba la rama de destino, trae cambios con el flujo acordado y verifica que el proyecto sigue funcionando antes de integrar.
  • Evitar credenciales y datos privados en el repositorio: utiliza configuración segura, permisos adecuados y mecanismos de secretos; revisa lo que vas a confirmar y publicar.
  • Documentar cómo se trabaja: indica cómo clonar el proyecto, qué rama usar, cómo ejecutar las pruebas y cómo proponer cambios.
  • Usar etiquetas para identificar versiones importantes: el equipo puede asociar una etiqueta anotada a una entrega que quiera consultar o reproducir.

7. Errores frecuentes

Error frecuente Por qué ocurre Cómo evitarlo
Pensar que git add guarda el cambio en el historial. Se confunde el área de preparación con un commit. Recuerda la secuencia: editar, preparar con git add y confirmar con git commit.
Creer que un commit aparece automáticamente en GitHub. Se confunde el repositorio local con el remoto. Ejecuta git push después de confirmar y comprueba la rama en GitHub.
Confirmar archivos que no se querían incluir. Se usa git add . sin revisar el estado o las diferencias. Ejecuta git status y git diff --staged; prepara archivos concretos cuando sea necesario.
Volver a editar después de git add y pensar que el cambio nuevo ya está preparado. El área de preparación conserva la versión añadida en ese momento. Vuelve a ejecutar git add para incluir la edición posterior y comprueba el diff preparado.
Ejecutar git reset --hard para limpiar cualquier problema. No se distingue entre mover una referencia y descartar trabajo local. Comprueba el estado y usa una operación adecuada; --hard puede borrar cambios rastreados no confirmados.
Usar git rebase sobre commits que ya utiliza el equipo. Se ignora que rebase reescribe el historial. Limita el rebase a commits locales no compartidos y coordina cualquier reescritura necesaria.
Añadir una contraseña al repositorio y confiar en .gitignore para borrarla. .gitignore no retira archivos ya seguidos ni borra commits anteriores. No publiques secretos; si ocurre, revoca la credencial y sigue el procedimiento para sanear el historial.
Abrir una PR demasiado grande o sin explicar qué se ha probado. Se agrupan tareas o se deja la revisión para el resto del equipo. Divide el trabajo y describe el objetivo, el contexto y las comprobaciones realizadas.

8. Resumen

En este tema has aprendido que:

  • Git registra el historial del proyecto en repositorios y GitHub ofrece un servicio remoto y herramientas colaborativas; no son la misma cosa;
  • los cambios pasan del directorio de trabajo al área de preparación y, con un commit, al historial local; push y pull sincronizan el trabajo con un remoto;
  • las ramas aíslan líneas de trabajo, las fusiones y los rebases las integran de formas distintas, y los conflictos requieren revisar el contenido;
  • las pull requests permiten proponer y revisar cambios, mientras que los flujos Git Flow, GitHub Flow y Trunk Based Development organizan la colaboración de maneras diferentes;
  • revisar el estado, usar commits claros y proteger credenciales reduce errores y mejora la seguridad del proyecto.

Idea clave

Git conserva y organiza la historia de un proyecto; el equipo decide cómo revisar y compartir esa historia. Antes de confirmar, integrar o publicar cambios, comprueba qué operación vas a realizar y qué información estás compartiendo.

9. Para seguir practicando

  • Realiza la práctica de documentación y GitHub Actions: clona el repositorio o tu fork, revisa su historial y relaciona las PR, los commits y la automatización que utiliza.
  • En un repositorio de prueba, crea una rama feature, modifica un archivo, revisa git status y git diff, prepara solo ese archivo y confirma el cambio. Después, integra la rama.
  • Simula dos cambios incompatibles en un fichero de prueba, resuelve el conflicto sin dejar marcadores y documenta qué comando utilizaste para completar la fusión.

Bibliografía y fuentes

Presentación