Gestión del Código Fuente

La gestión del código fuente (SCM, por sus siglas en inglés) es la disciplina de rastrear, registrar y coordinar cada cambio realizado en el código fuente de un proyecto a lo largo del tiempo. Esta página explica qué es la SCM, por qué todos los equipos dependen de ella, cómo encaja Git en este contexto, el flujo de trabajo que habilita y las prácticas que mantienen limpio el historial de un proyecto.

¿Qué Es la Gestión del Código Fuente?

La gestión del código fuente es la práctica de rastrear y administrar los cambios en el código de software. Casi siempre se implementa con un sistema de control de versiones (VCS) — una herramienta que registra cada modificación en un repositorio, la atribuye a un autor, le asigna una marca de tiempo y te permite moverte hacia adelante y hacia atrás en el historial del proyecto.

Git es el VCS más utilizado hoy en día. Es distribuido, lo que significa que cada desarrollador mantiene una copia completa del historial del proyecto de forma local, por lo que puedes hacer commits, crear ramas e inspeccionar el historial sin necesidad de conexión a la red. Existen otros sistemas (Subversion, Mercurial, Perforce), pero los conceptos de esta página se aplican a todos ellos.

SCM y VCS se usan frecuentemente de forma intercambiable. En sentido estricto, SCM es la práctica más amplia (historial, ramificación, políticas de colaboración, revisión de código), y un VCS como Git es la herramienta que la implementa.

Si eres nuevo en Git, comienza con la introducción a Git y aprende a crear tu primer repositorio Git.

Por Qué Es Importante la Gestión del Código Fuente

Un VCS resuelve problemas que se vuelven dolorosos en el momento en que más de una persona — o más de un día de trabajo — toca una base de código:

• Rastrear cambios – Cada cambio se registra automáticamente, se atribuye a un autor y se documenta con un mensaje de commit, creando un historial con capacidad de búsqueda.
• Sincronización – Los miembros del equipo obtienen el código más reciente de un repositorio compartido, de modo que todos trabajan desde la misma base.
• Copia de seguridad y restauración – Dado que cada commit es una instantánea completa, cualquier archivo puede restaurarse a un estado anterior en cualquier momento.
• Deshacer cambios – Puedes revertir a cualquier estado anterior, desde el commit más reciente hasta una versión creada hace mucho tiempo, sin perder los pasos intermedios.
• Ramificación y fusión – El trabajo ocurre en ramas aisladas y se fusiona de vuelta una vez revisado y aprobado.
• Detección de conflictos – Cuando dos personas cambian las mismas líneas, el VCS se niega a sobrescribir silenciosamente una con la otra; señala un conflicto de fusión para que una persona pueda resolverlo.

Sin SCM, los equipos recurren a comprimir carpetas, enviar archivos por correo electrónico y nombrar las cosas final_v2_REALLY_final.js — perdiendo el historial y sobreescribiendo el trabajo de los demás.

El Flujo de Trabajo Básico de SCM

La mayor parte del trabajo diario en Git sigue el mismo ciclo: cambiar archivos, prepararlos, hacer un commit de una instantánea e inspeccionar el historial. El ejemplo a continuación ejecuta un repositorio autocontenido para que puedas ver el ciclo de principio a fin.

# Create and enter a fresh project
mkdir scm-demo && cd scm-demo

# 1. Turn the folder into a repository
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

# 2. Make a change
echo "console.log('hello');" > app.js

# 3. Stage the change, then record a snapshot (commit)
git add app.js
git commit -q -m "Add initial app"

# 4. Make a second change and commit it
echo "console.log('world');" >> app.js
git commit -q -am "Print world too"

# 5. Inspect the historical record
git log --oneline

El historial ahora contiene dos instantáneas, la más reciente primero (los hashes cortos a la izquierda se generan por commit, por lo que los tuyos serán distintos):

6524bb9 Print world too
88e2f34 Add initial app

Cada git add mueve los cambios al área de preparación, y cada git commit congela el contenido preparado en una instantánea permanente y nombrada. La salida de git log es el registro histórico que te proporciona la SCM — dos líneas aquí, una por commit, cada una con un hash corto y un mensaje. En cualquier momento puedes ejecutar git status para ver qué ha cambiado, qué está preparado o qué no tiene seguimiento.

Ramificación y Fusión

La característica que hace poderosa a la SCM para los equipos es el aislamiento mediante ramas. Cada desarrollador (o cada funcionalidad) obtiene una línea de desarrollo separada; cuando el trabajo ha sido revisado y está listo, se fusiona de vuelta en la rama principal.

mkdir branch-demo && cd branch-demo
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

echo "line 1" > notes.txt
git add notes.txt
git commit -q -m "Start notes"

# Remember the main branch name (main or master)
main=$(git branch --show-current)

# Create a branch, switch to it, add work there
git switch -c feature
echo "line 2 from feature" >> notes.txt
git commit -q -am "Add feature line"

# Go back to the main branch and merge the feature in
git switch -q "$main"
git merge -q feature

cat notes.txt

Después de la fusión, notes.txt contiene el trabajo de ambas ramas:

line 1
line 2 from feature

La rama feature permitió que la nueva línea de trabajo avanzara sin tocar main, y git merge la combinó de vuelta. En un proyecto compartido también harías git clone del repositorio y git pull antes de empezar, de modo que construyas sobre el código más reciente.

Buenas Prácticas

• Haz commits con frecuencia, en unidades pequeñas. Un commit es una instantánea; los commits pequeños y enfocados te dan muchos puntos seguros a los que volver y hacen que el historial sea fácil de leer. Los commits relacionados pueden combinarse posteriormente para mantener el log limpio.
• Trabaja siempre desde la versión más reciente. Haz pull o fetch del código compartido antes de empezar para construir sobre el trabajo actual y minimizar los conflictos de fusión.
• Escribe mensajes de commit descriptivos. Un mensaje claro que explique qué cambió y por qué se vuelve esencial a medida que el proyecto crece y otras personas (incluyendo tu yo futuro) leen el log.
• Revisa antes de hacer commit. El área de preparación te permite recopilar e inspeccionar los cambios antes de convertirlos en una instantánea — revisa el diff para que cada commit sea deliberado.
• Usa ramas para el aislamiento. Desarrolla cada funcionalidad o corrección en su propia rama y fusiónala solo después de la revisión, manteniendo estable la rama principal.
• Acuerda un flujo de trabajo compartido. Establece convenciones de equipo para ramificación, revisión y fusión. Los patrones más comunes se tratan en flujos de trabajo de Git.

Práctica