PARCHE · 1.2.0 → 1.2.1
Corrección de un error. Nada de lo que ya funcionaba cambia de forma.
Se corrigió el cálculo del IVA.
Guardar trabajo a medias sin hacer commit
Situación clásica: llevas media hora con un cambio a medias y te piden corregir algo urgente en otra rama. No quieres hacer commit de algo incompleto, y Git no te deja cambiar de rama con cosas sin guardar.
Para eso existe git stash: aparta tus cambios en un cajón, deja la
carpeta limpia, y te los devuelve cuando vuelvas.
El cajón, en tres comandos
# Guardar lo que tengo a medias y dejar la carpeta limpia
git stash push -m "formato de la tabla a medias"
# Ver que hay guardado
git stash list
# Recuperarlo y sacarlo del cajon
git stash popResultado
Saved working directory and index state On main: formato de la tabla a medias
stash@{0}: On main: formato de la tabla a mediasEl cajón es para horas, no para semanas. Lo guardado ahí
no está en ningún commit, no viaja al servidor y no aparece en el historial: si
formateas el equipo, se pierde. Y un cajón con seis entradas sin nombre es
imposible de descifrar tres días después -por eso el -m.
Si el trabajo va a durar más de un día, lo suyo es una rama y un commit, aunque esté incompleto.
Marcar una versión
Un commit se llama a91c4e2, y eso no le dice nada a nadie. Una
etiqueta es un nombre legible que se le pega a un commit concreto
para poder volver a él: «la versión que se entregó al cliente en
septiembre».
A diferencia de una rama, una etiqueta no se mueve nunca. Marca un punto y ahí se queda.
Crear y publicar una etiqueta
# Etiqueta con mensaje, sobre el commit actual
git tag -a v1.2.0 -m "Tarifas del segundo semestre"
# Ver las que hay
git tag
# Las etiquetas NO viajan con un push normal
git push origin v1.2.0Resultado
v1.0.0 v1.1.0 v1.2.0
La última línea es la que se olvida siempre: git push
no sube las etiquetas. Hay que nombrarlas, o subirlas todas de golpe con
git push --tags.
Qué número poner
La convención más extendida es el versionado semántico:
tres números separados por puntos, MAYOR.MENOR.PARCHE. No es una regla
de Git, es un acuerdo -está publicado en semver.org- y sirve para que el número
comunique algo por sí solo.
Qué número sube, y cuándo
MENOR · 1.2.1 → 1.3.0
Algo nuevo, y lo anterior sigue funcionando igual.
Se añadió la plantilla de cotización por zonas.
MAYOR · 1.3.0 → 2.0.0
Un cambio que rompe la forma de usarlo: quien venía del anterior tiene que adaptarse.
Cambió la estructura completa del documento.
Proyecto final: el repositorio de un negocio
Vamos a montar algo que no es código, porque es donde mejor se ve para qué sirve Git de verdad: la carpeta de documentos operativos de una empresa -plantillas, tarifas, procedimientos, listas de chequeo-.
Son archivos que cambian, que alguien tiene que aprobar, y sobre los que constantemente se pregunta «¿desde cuándo dice esto?». Exactamente lo que Git responde.
El proyecto, de principio a fin
1. Crear la estructura
Una carpeta con subcarpetas por tema:
tarifas/,plantillas/,procedimientos/.Todo en formatos de texto -Markdown,
.csv,.txt- para que Git pueda mostrar qué línea cambió. Un.docxlo guarda igual, pero no te enseña la diferencia.2. .gitignore antes del primer commit
Fuera lo que no debe entrar nunca: credenciales, datos personales de clientes, borradores pesados.
Es el paso que no tiene arreglo si se salta (lección 2).
3. Iniciar y hacer el primer commit
git init,git add .tras mirargit status, ygit commit -m "docs: estructura inicial de tarifas y plantillas".4. Un cambio real en su rama
git switch -c feature/tarifas-segundo-semestre, subes los precios, commit con un mensaje que explique por qué suben.5. Fusionar y etiquetar
git switch main,git merge, ygit tag -a v1.0.0 -m "Tarifas vigentes desde julio".Ese punto queda marcado para siempre: es «lo que estaba vigente entonces».
6. Publicarlo en GitHub
Repositorio privado -son documentos internos-,
git remote add origin ...,git push -u origin mainygit push --tags.7. Comprobar que sirve
La prueba de fuego, y es la que cierra el curso: responde con un solo comando «¿desde cuándo la tarifa es esta y quién la cambió?».
git log --oneline -- tarifas/y luegogit show <id>. Si lo respondiste, el curso cumplió.
Ese repositorio no se queda en el ejercicio. Es la forma en que muchos
equipos llevan sus documentos operativos: cada cambio con su autor, su fecha y su
motivo, y la versión vigente marcada con una etiqueta. Sin una sola carpeta llamada
tarifas_final_ESTE_SI.
Costumbres que vale la pena adoptar desde hoy
Mirar git status antes y después de todo
Es medio segundo y evita la mayoría de los sustos del curso: el
add olvidado, la rama equivocada, el archivo que no debía
entrar.
Commits pequeños y frecuentes
Un commit por idea. Si el mensaje te pide un «y», son dos.
Los commits pequeños son fáciles de leer, fáciles de revertir y producen conflictos pequeños.
pull antes de empezar, push al terminar
Trabajar sobre lo último y no dejar tu trabajo solo en tu disco. Las dos costumbres juntas eliminan casi todos los conflictos grandes.
Nunca --force sobre lo compartido
Ni push --force, ni reset --hard sobre
commits que ya tienen otros. Para eso está revert, que corrige
añadiendo.
Compruébalo tú mismo
Corriges un error sin cambiar nada de cómo se usa. Venías de la 1.4.2. ¿Qué versión pones?
Sube el número de parche. El menor se reserva para cosas nuevas
y el mayor para cambios que rompen la forma de usarlo.
Hiciste git tag v1.0.0 y luego git push. ¿Está la etiqueta en GitHub?
Un
push normal sube commits, no etiquetas. Es de
los olvidos más frecuentes al publicar una versión.¿Cuándo NO conviene usar git stash?
Lo guardado en el cajón no está en ningún commit ni viaja al
servidor. Para horas es cómodo; para días es un riesgo.
Hasta dónde llegaste
Sabes crear un repositorio, guardar historial con mensajes que sirven,
leerlo, abrir ramas para probar sin romper, deshacer en los cuatro escenarios,
trabajar contra GitHub y resolver un conflicto sin ayuda. Eso es el uso real de Git
en un equipo: lo que queda fuera -rebase, submódulos, ganchos- se
aprende el día que haga falta, y no hace falta casi nunca.
El certificado se saca en el aula. Las preguntas de estas lecciones son para que te comprobaras a ti mismo: no guardan nota. La evaluación que certifica se presenta en el Aula Virtual, con tu cuenta, y al aprobarla se emite el certificado a tu nombre.
Por dónde seguir
Git es la base de todo trabajo técnico en equipo, así que encaja con casi todo lo demás. Si vas hacia la administración de sistemas, el paso natural es Servidores Linux: entrar por SSH -la misma llave que usaste aquí- y manejar una máquina sin pantalla. Si lo tuyo son los datos, Bases de datos SQL. Y si aún no lo has hecho, Seguridad digital explica por qué la credencial que dejaste fuera del repositorio importaba tanto.
Terminaste Git básico. Presenta la evaluación y reclama tu certificado.
Quiero mi certificado ← Fusionar y resolver conflictos