Capítulo 5. Trabajando con Git desde Visual Studio Code¶

Introducción¶

Hasta este punto del libro, el trabajo con Git se ha realizado principalmente desde la terminal. Ese enfoque sigue siendo fundamental porque permite comprender con claridad qué sucede en cada etapa: qué archivos cambian, cuáles entran al área de preparación, cuándo se crea un commit y en qué momento los cambios se envían al repositorio remoto. Sin embargo, en el trabajo diario también es muy común utilizar herramientas visuales que aceleran tareas repetitivas y hacen más evidente el estado del proyecto.

Visual Studio Code incorpora integración nativa con Git y presenta una vista de control de versiones pensada para revisar cambios, preparar archivos, crear commits y sincronizar con GitHub sin salir del editor. Esta integración no sustituye a Git ni crea un sistema alternativo: VS Code usa la instalación de Git del sistema y ejecuta sobre ella las operaciones habituales del repositorio.

En este capítulo se continuará trabajando sobre el mismo proyecto iniciado en el Capítulo 2. No se creará un repositorio nuevo ni se introducirán flujos avanzados; el enfoque será estrictamente práctico y centrado en el uso diario del panel Source Control para modificar archivos, revisar diferencias, preparar cambios, registrar commits y sincronizar con GitHub.

La meta no es que el lector abandone la terminal, sino que aprenda a combinar ambos estilos de trabajo de forma profesional. Un desarrollador sólido puede revisar cambios visualmente en VS Code, preparar archivos con un clic, crear un commit desde la interfaz y, al mismo tiempo, entender que detrás de esas acciones siguen existiendo comandos concretos de Git como git add, git commit, git pull y git push.

5.1 ¿Por qué utilizar Visual Studio Code con Git?¶

Trabajar con Git desde Visual Studio Code tiene una ventaja inmediata: reúne edición de código y control de versiones en un mismo entorno. En lugar de cambiar constantemente entre el editor y la terminal para revisar cada modificación, el desarrollador puede escribir, guardar, inspeccionar diferencias y preparar archivos desde la misma ventana. Esto reduce fricción y hace más fluido el ciclo diario de trabajo.

Otra ventaja importante es la integración nativa. VS Code detecta automáticamente cuando se abre una carpeta que ya es un repositorio Git y habilita las funciones de control de versiones sin requerir extensiones adicionales para lo básico. Siempre que Git esté instalado en el sistema, el editor puede mostrar el estado del repositorio, listar cambios, abrir comparaciones visuales, crear commits y sincronizar con un remoto.

Desde una perspectiva pedagógica, la interfaz visual ayuda mucho a relacionar conceptos abstractos con acciones visibles. El área de preparación deja de ser una idea teórica y pasa a verse como una lista concreta de archivos bajo Staged Changes; los cambios sin preparar aparecen en Changes; y el historial se vuelve más fácil de explorar al observar confirmaciones anteriores desde los paneles disponibles.

Aun así, utilizar VS Code con Git no significa depender exclusivamente de la interfaz gráfica. En el trabajo profesional hay momentos en los que la vista visual resulta ideal y otros en los que la terminal sigue siendo más rápida, más precisa o simplemente más expresiva.

Cuándo conviene usar la interfaz gráfica¶

La interfaz gráfica de VS Code resulta especialmente útil en tareas como estas:

Revisar rápidamente qué archivos fueron modificados, nuevos o preparados.
Abrir comparaciones visuales para identificar líneas agregadas, eliminadas o editadas.
Preparar uno o varios archivos con clics individuales sin escribir comandos repetitivos.
Crear commits cortos y frecuentes mientras se observa exactamente qué quedará registrado.
Sincronizar cambios con el remoto mediante acciones visibles como Sync Changes, Push o Pull.

En proyectos reales, esta capa visual reduce errores comunes. Es más difícil hacer un commit precipitado cuando la interfaz obliga a ver la lista de archivos modificados y facilita revisar uno por uno antes de confirmar.

Cuándo conviene usar la terminal¶

La terminal sigue siendo preferible en varias situaciones:

Cuando se necesita escribir comandos encadenados o automatizar tareas.
Cuando se quiere verificar el estado exacto del repositorio con salidas textuales como git status.
Cuando se trabaja en sesiones remotas, entornos mínimos o servidores sin interfaz gráfica.
Cuando surge un problema que exige comandos más específicos que los visibles en la interfaz.
Cuando se desea aprender Git con profundidad y no solo memorizar botones.

Git fue diseñado como una herramienta de línea de comandos, y su documentación oficial describe las operaciones esenciales a partir de comandos como git add y git commit. Por eso, la terminal sigue siendo la referencia conceptual más importante, incluso cuando la operación concreta se ejecuta desde VS Code.

Interfaz gráfica y terminal lado a lado¶

Situación	Interfaz de VS Code	Terminal
Revisar cambios archivo por archivo	Muy cómoda y visual.	Posible, pero menos visual para principiantes.
Preparar uno o varios archivos	Rápida con iconos `+`.	Precisa con `git add`.
Escribir commits frecuentes	Cómodo desde el cuadro de mensaje.	Flexible con `git commit -m`.
Ver equivalencia exacta de acciones	Menos explícita	Más clara para entender Git
Automatizar flujos	Limitada	Muy adecuada
Diagnosticar problemas	Útil para lo básico	Mejor para casos avanzados

Buenas prácticas

Un desarrollador profesional no elige entre interfaz gráfica o terminal como si fueran rivales. Domina ambas, entiende sus equivalencias y usa la que aporte más claridad o velocidad según la tarea.

Ejemplo aplicado al proyecto del libro¶

Supongamos que en el proyecto del libro se modifican tres archivos: README.md, index.html y css/estilos.css. Desde VS Code, el lector puede guardar los cambios, abrir Source Control, revisar cada diferencia visualmente y preparar solo los archivos que pertenecen a una mejora concreta. Si después necesita comprobar el estado exacto del repositorio, puede abrir la terminal integrada y ejecutar git status para confirmar que la interfaz y Git están mostrando lo mismo.

Este tipo de combinación es la que se espera en entornos profesionales: usar la vista visual para comprender con rapidez y la terminal para verificar, documentar o ejecutar acciones más específicas. La productividad no proviene de depender de un único método, sino de saber alternarlos con criterio.

Conclusión de la sección¶

Visual Studio Code aporta velocidad, contexto visual e integración directa con Git, mientras que la terminal mantiene el nivel más preciso de control y comprensión. La práctica profesional no consiste en reemplazar una por otra, sino en convertir ambas en herramientas complementarias dentro del mismo flujo de trabajo.

5.2 Conociendo el panel Source Control¶

El panel Source Control es el centro de operaciones de Git dentro de Visual Studio Code. Desde ahí se pueden observar los cambios detectados por el repositorio, preparar archivos, escribir mensajes de commit, consultar parte del historial y ejecutar operaciones de sincronización con el remoto.

Para abrirlo, normalmente basta con seleccionar el icono de control de versiones en la barra lateral izquierda o usar el atajo indicado por VS Code para esa vista. Cuando la carpeta abierta ya es un repositorio Git, el panel se activa automáticamente y comienza a listar cambios tan pronto como se guardan archivos modificados.

El icono de Source Control¶

En la barra de actividad de VS Code, el icono de Source Control funciona como un indicador rápido del estado del repositorio. Además de permitir abrir la vista, suele mostrar una insignia numérica con la cantidad de archivos afectados por cambios pendientes. Esa cifra ayuda a detectar de inmediato si el proyecto tiene modificaciones sin registrar.

Esto se relaciona directamente con lo aprendido en capítulos anteriores: si Git detecta diferencias entre el directorio de trabajo y el último commit, entonces el repositorio ya no está “limpio”. VS Code representa esa situación visualmente para que no dependa solo de la ejecución de git status en la terminal.

[Ilustración: captura de Visual Studio Code con la barra lateral izquierda visible, resaltando el icono de Source Control y una insignia numérica que indica archivos con cambios pendientes; debe apreciarse también el proyecto abierto en el explorador y la relación entre el editor y el panel de control de versiones.]

Cambios detectados¶

Cuando se modifica un archivo del proyecto y se guarda, VS Code muestra ese archivo en la sección Changes del panel Source Control. Esa lista corresponde, en términos de Git, a cambios presentes en el directorio de trabajo que todavía no han sido confirmados en un commit.

Cada archivo aparece acompañado de indicadores cortos y colores que permiten reconocer su estado. En la guía rápida oficial de VS Code se destacan, entre otros, U para archivos sin seguimiento y M para archivos modificados.¹ Esto permite interpretar visualmente el mismo tipo de información que en terminal se consultaría con git status.

Archivos modificados¶

Un archivo modificado es uno que ya existía en el repositorio y cuyo contenido cambió respecto al último commit. VS Code lo marca con la letra M y lo incluye en la lista de cambios pendientes. En el proyecto del libro, esto ocurrirá con frecuencia al editar archivos ya creados en capítulos anteriores, por ejemplo una página HTML o una hoja de estilos.

Cuando el lector ve un M, debe pensar lo siguiente: Git detectó que el archivo ya era parte del repositorio, pero su versión actual contiene diferencias aún no registradas. No significa que el archivo esté listo para el commit; solo significa que cambió.

Archivos nuevos¶

Si se crea un archivo nuevo dentro del proyecto, VS Code lo muestra con la letra U, asociada a untracked o “sin seguimiento”. En otras palabras, Git sabe que el archivo existe en la carpeta del proyecto, pero todavía no forma parte del historial del repositorio porque no ha sido preparado ni confirmado.

Este detalle es crucial porque muchos principiantes creen que guardar un archivo dentro de un repositorio basta para que Git lo registre. No es así. Mientras no se agregue al área de preparación, seguirá apareciendo como nuevo y fuera del historial.

Indicadores visuales dentro del editor¶

Además del panel Source Control, VS Code utiliza señales dentro del propio editor para reflejar el estado de los cambios. La documentación oficial destaca la presencia de indicadores en el margen o gutter del editor para mostrar diferencias en el archivo que se está editando. Gracias a esto, no hace falta abrir siempre una comparación completa para saber qué partes fueron alteradas.

Esos marcadores suelen aparecer junto a las líneas afectadas y actúan como pistas rápidas sobre agregados, modificaciones o eliminaciones. En la práctica, permiten desplazarse por un archivo largo y ubicar de inmediato las zonas editadas desde el último commit.

Relación con conceptos previos¶

Todo lo que se observa en Source Control tiene una traducción directa a los conceptos fundamentales de Git ya estudiados:

Elemento en VS Code	Concepto de Git relacionado
Changes	Cambios en el directorio de trabajo aún no preparados.
Staged Changes	Área de preparación o staging area.
Cuadro de mensaje	Mensaje del commit.
Botón Commit	Ejecución de `git commit` sobre lo preparado.
Botón Sync Changes	Coordinación de `pull` y `push` con el remoto.

Esta equivalencia es una de las mayores fortalezas didácticas de VS Code: convierte conceptos que podrían parecer invisibles en componentes observables. El lector no solo memoriza que existe un área de preparación; la ve, la llena con archivos y la vacía después de un commit.

Nota

Que una acción se realice con botones no cambia la lógica de Git. VS Code no evita las etapas del flujo; solo las presenta de forma visual y accesible.

Error común en esta etapa¶

Error común

Abrir el panel Source Control, ver muchos archivos listados y hacer commit sin revisar qué cambió en cada uno. La interfaz está diseñada precisamente para facilitar la revisión; ignorarla equivale a renunciar a una de sus mayores ventajas.

Ejemplo guiado en el proyecto del libro¶

Abre en VS Code el mismo repositorio del libro usado desde el Capítulo 2.
Modifica un texto en README.md.
Agrega un comentario o una mejora menor en un archivo HTML del proyecto.
Crea un archivo nuevo de apoyo, por ejemplo notas-cambios.md, si la práctica lo requiere.
Guarda todos los archivos.
Abre Source Control y observa cómo los archivos existentes aparecen como modificados y el archivo nuevo como no rastreado.

En este punto el lector ya puede relacionar visualmente el estado de cada archivo con el comportamiento real de Git. Esa comprensión hará mucho más natural el proceso de preparación y commit en las secciones siguientes.

Conclusión de la sección¶

El panel Source Control organiza de forma clara el estado del repositorio y traduce conceptos clave de Git en señales visuales concretas. Entender cómo leer sus iconos, listas e indicadores es el paso decisivo para trabajar con confianza desde VS Code sin perder la lógica interna del control de versiones.

5.3 Visualizando cambios¶

Revisar cambios antes de crear un commit es una práctica profesional básica. VS Code facilita esta tarea mediante su editor de diferencias o diff editor, que permite comparar la versión actual de un archivo con la última versión confirmada en Git. En lugar de leer el archivo completo tratando de recordar qué cambió, el desarrollador observa únicamente las líneas afectadas.

Comparación entre versiones¶

Cuando se selecciona un archivo en la lista de Changes, VS Code abre una comparación visual entre dos estados del archivo: la versión registrada previamente en el repositorio y la versión actual del directorio de trabajo. Si el espacio de la ventana es suficiente, la comparación suele mostrarse lado a lado; si no, puede presentarse en modo integrado o en línea.

Esta vista es mucho más que una comodidad visual. Representa, de manera concreta, la diferencia entre lo ya confirmado y lo todavía no registrado. En otras palabras, muestra exactamente lo que entraría en un futuro commit si ese archivo se prepara y confirma.

[Ilustración: captura del editor de diferencias de VS Code comparando un archivo del proyecto del libro, con la versión anterior a la izquierda y la actual a la derecha, resaltando líneas añadidas, líneas eliminadas y bloques modificados, además de los marcadores de color en el margen del editor.]

Líneas agregadas¶

Las líneas nuevas aparecen destacadas con el color asociado a adiciones. La documentación de VS Code explica que el editor utiliza indicadores visuales en el margen para mostrar diferencias, lo que incluye nuevas líneas agregadas al archivo. En la práctica, el lector debe interpretar estas líneas como contenido que no existía en el último commit y que ahora forma parte de la versión actual.

En el proyecto del libro, esto podría ocurrir al añadir una nueva sección descriptiva en README.md, una nueva regla CSS o un nuevo bloque de contenido HTML. Si esas líneas se ven marcadas como agregadas, Git las considera una incorporación pendiente de registrar.

Líneas eliminadas¶

Cuando una línea existía en la versión anterior pero desaparece en la versión actual, VS Code la muestra como eliminada en la comparación. Este tipo de cambio es importante porque borrar contenido también modifica el historial del proyecto, aunque visualmente a veces pase más desapercibido que agregar texto nuevo.

Una eliminación puede ser correcta, por ejemplo al retirar código duplicado o texto obsoleto. Pero también puede señalar un error, como haber borrado accidentalmente un bloque útil. Por eso conviene revisar con cuidado cualquier cambio de este tipo antes de preparar el archivo.

Modificaciones¶

Muchas veces un cambio no consiste solo en agregar o eliminar, sino en sustituir una línea por otra. En esos casos, la comparación refleja una modificación: parte del contenido anterior desaparece y una nueva versión ocupa su lugar. Esto es muy frecuente al corregir texto, renombrar clases CSS o ajustar rutas internas del proyecto.

Desde la perspectiva de Git, una modificación es la combinación de una eliminación y una adición. VS Code la presenta de forma visual para que el lector pueda entender rápidamente qué cambió exactamente sin tener que reconstruir mentalmente el archivo completo.

Colores y marcadores de VS Code¶

Uno de los aportes más valiosos de VS Code es la consistencia visual con la que representa diferencias. La documentación oficial menciona tanto el diff editor como los indicadores del margen del editor para mostrar cambios directamente mientras se trabaja. Eso significa que hay dos niveles de lectura visual:

Una vista detallada al abrir la comparación completa del archivo.
Una vista rápida desde los marcadores del margen mientras se edita.

Aunque los temas visuales pueden variar ligeramente en apariencia, la idea general se mantiene: los colores y señales ayudan a distinguir adiciones, eliminaciones y modificaciones. El lector debe acostumbrarse a interpretar esos marcadores como alertas de cambio, no como simple decoración de la interfaz.

Comparación visual y revisión profesional¶

Revisar cambios visualmente antes de preparar archivos ofrece varias ventajas concretas:

Permite detectar errores de tipeo antes del commit.
Evita subir cambios accidentales en archivos que no debían modificarse.
Ayuda a escribir mensajes de commit más precisos, porque se entiende mejor el alcance real del cambio.
Reduce el riesgo de sincronizar trabajo incompleto con GitHub.

Consejo

Antes de preparar todos los archivos con un solo clic, abre al menos los cambios más importantes. Un commit claro empieza con una revisión clara.

Ejemplo guiado: revisando cambios del proyecto¶

Supón que el lector realiza estas ediciones en el mismo repositorio del libro:

Cambia el título de una sección en README.md.
Ajusta el color de un botón en css/estilos.css.
Corrige un enlace roto en index.html.

Paso a paso:

Guarda los archivos.
Abre Source Control.
Haz clic sobre README.md y observa la comparación entre la versión anterior y la actual.
Identifica qué línea fue reemplazada y verifica que el nuevo título sea el correcto.
Repite el proceso con css/estilos.css y confirma que el cambio afectó solo la regla esperada.
Revisa index.html y comprueba que el enlace corregido no haya modificado otras rutas por accidente.

Este hábito de revisión es más importante de lo que parece. Muchos errores pequeños no se originan al escribir código, sino al confirmar cambios no revisados.

Relación con la terminal¶

Desde la terminal también es posible comparar cambios con comandos específicos, pero VS Code traduce esa revisión a una experiencia visual inmediata. La terminal sigue siendo útil para usuarios avanzados; no obstante, para inspección rápida archivo por archivo, la vista gráfica del editor suele ser más eficiente y más amigable durante el trabajo diario.

¿Sabías que...?

VS Code puede mostrar diferencias no solo en la vista de comparación completa, sino también con marcas visibles en el margen del archivo abierto. Eso permite detectar zonas modificadas mientras todavía se está editando.

Conclusión de la sección¶

Visualizar cambios en VS Code convierte la revisión previa al commit en una tarea rápida, precisa y muy natural dentro del editor. Aprender a leer el diff, los colores y los marcadores ayuda a confirmar solo cambios correctos y evita que el historial del proyecto se llene de errores innecesarios.

5.4 Preparando cambios¶

En Git, preparar cambios significa mover archivos desde el directorio de trabajo hacia el área de preparación, también llamada staging area o índice. La documentación oficial de git add define precisamente esa función: agregar el contenido de archivos al índice para que pueda formar parte del siguiente commit. VS Code permite realizar este proceso desde la interfaz gráfica sin dejar de respetar esa misma lógica interna.

Agregar archivos individualmente¶

Cuando un archivo aparece en la sección Changes, se puede preparar de forma individual colocando el cursor sobre su nombre y seleccionando el icono +. También es posible hacerlo mediante el menú contextual con la opción Stage Changes.

La equivalencia directa en Git es:

git add nombre-del-archivo

Ese detalle es esencial: el botón no “guarda” el cambio ni crea todavía un commit. Solo mueve ese archivo al área de preparación para dejarlo listo para la siguiente confirmación.

Agregar todos los cambios¶

Si varios archivos pertenecen a la misma modificación lógica, VS Code permite prepararlos todos de una sola vez con el icono + ubicado en el encabezado de la sección Changes. Esta acción resulta muy útil cuando el cambio es coherente y se desea incluir completo en un único commit.

La equivalencia general en terminal sería una variante de git add aplicada a todos los cambios pertinentes. Lo importante, más allá del comando exacto, es comprender que todos esos archivos pasarán a Staged Changes y quedarán listos para confirmarse juntos.

Buenas prácticas

Preparar todo con un solo clic solo es recomendable cuando los archivos modificados forman parte del mismo objetivo. Si los cambios responden a tareas distintas, conviene preparar solo los archivos relacionados con una de ellas y dejar el resto para otro commit.

Retirar archivos del área de preparación¶

Así como un archivo puede entrar al área de preparación, también puede salir de ella antes del commit. En VS Code, los archivos preparados se muestran en la sección Staged Changes, y al pasar el cursor sobre uno de ellos aparece el icono - para retirarlo de esa área.

Desde la lógica de Git, esto equivale a deshacer la preparación del archivo sin borrar sus modificaciones del directorio de trabajo. Es decir, el contenido editado sigue existiendo, pero deja de formar parte del próximo commit.

Cambios, Staged Changes y claridad mental¶

Una de las mayores virtudes del panel Source Control es que obliga a pensar el trabajo en dos niveles visibles:

Lo que cambió pero todavía no está preparado: Changes.
Lo que ya está listo para entrar al commit: Staged Changes.

Esta separación ayuda a construir un criterio profesional para los commits. No todo cambio debe entrar automáticamente en la siguiente confirmación; primero debe revisarse, agruparse y prepararse con intención.

Acciones de VS Code y equivalencia en Git¶

Acción en VS Code	Qué hace	Equivalencia conceptual en Git
+ junto a un archivo	Prepara un archivo específico.	`git add archivo`
+ en el encabezado de Changes	Prepara todos los cambios visibles.	`git add` aplicado al conjunto de cambios
- junto a un archivo preparado	Quita ese archivo del área de preparación.	Retirar del índice sin perder cambios
Abrir un archivo desde Changes	Permite revisarlo antes de preparar.	Flujo equivalente a inspeccionar antes de `git add`

Ejemplo guiado: preparar correctamente en el proyecto del libro¶

Supongamos que el lector hizo estas modificaciones:

README.md: actualizó la descripción del proyecto.
index.html: corrigió un subtítulo.
css/estilos.css: ajustó espaciados visuales.
notas-personales.txt: creó un archivo temporal que no desea confirmar todavía.

Flujo sugerido:

Abrir Source Control.
Revisar visualmente los cuatro archivos.
Preparar README.md, index.html y css/estilos.css con el icono + porque sí forman parte de la mejora actual.
Dejar notas-personales.txt fuera del área de preparación porque no pertenece al cambio que se desea registrar.
Verificar que los tres archivos preparados se hayan movido a Staged Changes.

Este ejemplo muestra una idea central del trabajo profesional: preparar no es simplemente “seleccionar todo”, sino decidir qué conjunto de cambios constituye una unidad lógica de historial.

Error común: olvidar preparar archivos¶

Error común

Escribir un mensaje de commit y pulsar Commit creyendo que todos los cambios quedarán guardados, cuando en realidad algunos archivos siguen en Changes y no entrarán en la confirmación. Git registra solo lo que está preparado.

Error común: preparar de más¶

Otro error frecuente es preparar todos los archivos por costumbre, incluso aquellos que contienen pruebas incompletas, correcciones no relacionadas o cambios accidentales. La facilidad del botón + general no debe confundirse con una invitación a confirmar sin criterio.

Conclusión de la sección¶

Preparar cambios en VS Code es una traducción visual del uso de git add: seleccionar con intención qué archivos entrarán al siguiente commit. Entender la diferencia entre Changes y Staged Changes permite construir un historial más limpio, más claro y mucho más profesional.

5.5 Creando commits desde VS Code¶

Una vez que los archivos correctos están en Staged Changes, el siguiente paso es crear un commit. La documentación oficial de Git define git commit como la operación que crea un nuevo commit con el contenido actual del índice y el mensaje proporcionado. VS Code lleva esa misma lógica a una interfaz simple: escribir un mensaje, confirmar y registrar el cambio en el historial local.

El cuadro de mensaje¶

En la parte superior del panel Source Control aparece un cuadro de texto destinado al mensaje del commit. Ese mensaje debe describir con claridad qué cambio se está registrando. No es un simple comentario decorativo: será la referencia visible en el historial local y también en plataformas como GitHub cuando el commit se sincronice.

Un buen mensaje permite entender el propósito del cambio sin necesidad de abrir inmediatamente el diff. Por ejemplo:

Actualiza la descripción inicial del proyecto
Corrige enlace roto en la página principal
Ajusta estilos del encabezado en la portada

En cambio, mensajes como estos resultan pobres:

cambios
update
arreglo
prueba

Crear el commit¶

Después de escribir el mensaje, se utiliza la acción Commit del panel para registrar los cambios preparados en el historial. Tras el commit, los archivos dejan de aparecer en Staged Changes porque ya forman parte de una confirmación local guardada por Git.

La equivalencia en terminal es directa:

git commit -m "Mensaje descriptivo"

La idea clave es recordar que el commit se construye con lo preparado, no con todo lo que exista en el directorio de trabajo. Si quedan archivos sin preparar, esos cambios continuarán pendientes para un commit posterior.

Historial¶

Después de confirmar los cambios, el nuevo commit pasa a formar parte del historial del repositorio. GitHub Docs explica que cada commit recibe un identificador único, llamado SHA o hash, y registra quién lo creó, cuándo se hizo y qué cambios contiene.² Ese detalle ayuda a entender por qué los commits son la unidad básica de rastreo dentro del proyecto.

VS Code permite consultar el historial mediante herramientas integradas como la vista de historial y componentes relacionados como el Source Control Graph o la Timeline view según el contexto. Aunque en este capítulo no se profundizará en funciones avanzadas, sí conviene que el lector sepa que el commit recién creado no desaparece al cerrar el editor: queda grabado en la historia local del repositorio.

Buenas prácticas para commits¶

Un commit profesional suele cumplir estas características:

Representa una sola idea o cambio lógico.
Incluye solo los archivos relacionados con ese objetivo.
Tiene un mensaje claro y específico.
Se crea después de revisar visualmente las diferencias.
Puede entenderse más tarde sin necesidad de recordar el contexto exacto del día.

Buenas prácticas

Es mejor hacer varios commits pequeños y claros que uno enorme y confuso. Un historial ordenado facilita revisar, corregir y comprender la evolución del proyecto.

Ejemplo guiado: commit desde la interfaz¶

Supongamos que el lector ya revisó y preparó estos archivos del proyecto del libro:

README.md
index.html
css/estilos.css

Paso a paso:

Confirma que los tres archivos estén en Staged Changes.
Escribe en el cuadro de mensaje: Actualiza contenido inicial y estilos de presentación.
Pulsa Commit.
Verifica que la lista de archivos preparados quede vacía.
Observa si aún quedan archivos en Changes; si los hay, significa que no formaron parte del commit actual.

Este pequeño control posterior es muy útil, porque permite detectar inmediatamente si el commit quedó incompleto o si accidentalmente se dejó trabajo pendiente.

Relación con lo aprendido antes¶

En capítulos previos se aprendió que Git sigue una secuencia: modificar, preparar y confirmar. VS Code no altera ese modelo; simplemente lo expresa con controles visuales en el mismo orden. Por eso, comprender la interfaz es mucho más fácil cuando ya se entiende la lógica subyacente del comando git commit.

Error común: mensajes poco descriptivos¶

Error común

Confirmar un cambio con mensajes como fix, cambio 2 o actualizado. El commit quedará guardado, pero el historial perderá claridad y valor documental. Un buen mensaje debe describir el propósito del cambio, no solo indicar que algo ocurrió.

Curiosidad útil¶

Curiosidad

Git no almacena únicamente archivos “sueltos”; cada commit es un punto de referencia completo dentro de la historia del proyecto, identificado con un hash único. Esa es una de las razones por las que el historial puede inspeccionarse con tanta precisión después.

Conclusión de la sección¶

Crear commits desde VS Code es un proceso simple, pero exige criterio profesional al elegir qué preparar y cómo describirlo. La interfaz facilita la acción; la calidad del historial depende del hábito del desarrollador.

5.6 Sincronizando con GitHub¶

Hasta ahora, los commits creados desde VS Code existen en el repositorio local. Para que también aparezcan en GitHub, es necesario sincronizarlos con el repositorio remoto. VS Code ofrece varias acciones para esto, incluyendo Sync Changes, así como operaciones individuales de Push y Pull disponibles en la interfaz.

Botón Sync Changes¶

La guía rápida de VS Code indica que, cuando el repositorio está conectado a un servidor remoto, se puede usar Sync Changes para traer cambios del servidor y enviar los commits locales. También se puede acceder a esta sincronización desde el estado mostrado en la barra inferior cuando existe una rama conectada a un remoto.

En términos prácticos, Sync Changes funciona como una acción de sincronización conveniente para coordinar el intercambio de cambios entre el repositorio local y el remoto. Es ideal cuando el lector desea trabajar desde la interfaz sin lanzar comandos separados para cada operación.

Push¶

La operación Push envía los commits locales al repositorio remoto para que queden publicados en GitHub. En el flujo del capítulo, esto significa que los commits creados desde VS Code dejarán de existir solo en la computadora del usuario y pasarán a formar parte del historial visible del repositorio remoto.

Internamente, Git toma los commits locales que el remoto todavía no tiene y los transfiere a la referencia remota correspondiente. Aunque la interfaz muestre un botón, el principio no cambia: sin push, GitHub no reflejará los commits locales.

Pull¶

La operación Pull hace el movimiento complementario: trae cambios del remoto al repositorio local. Si otro cambio ya existe en GitHub pero todavía no está en la copia local, esta operación permite incorporarlo para mantener el proyecto actualizado.

En el trabajo diario, esto es importante incluso cuando una sola persona desarrolla el proyecto. Por ejemplo, si el lector realizó un cambio desde otra computadora o desde la propia interfaz web de GitHub, su entorno local podría quedar desfasado hasta ejecutar una actualización.

Publicación automática y publicación inicial¶

La documentación oficial de VS Code también menciona la posibilidad de Publish to GitHub para publicar un repositorio local directamente en GitHub cuando aún no existe el remoto. En este capítulo no se creará un proyecto nuevo, pero conviene entender la diferencia conceptual:

Publish to GitHub: se usa para publicar un repositorio local que todavía no está conectado a un remoto.
Push / Pull / Sync Changes: se usan cuando esa conexión remota ya existe y solo se desea mantener ambos lados sincronizados.

Como el proyecto del libro viene trabajándose desde capítulos anteriores, aquí se asume que el repositorio ya está vinculado con GitHub. Por tanto, el foco está en sincronizar cambios existentes, no en publicar desde cero.

¿Qué sucede internamente?¶

Aunque VS Code simplifica el proceso con botones, internamente siguen ocurriendo acciones propias de Git:

Git identifica el estado actual de la rama local.
Compara si hay commits entrantes o salientes respecto al remoto, información que VS Code puede mostrar en su barra de estado y en la vista de control de código fuente.
Si se ejecuta Pull, Git descarga e integra los cambios remotos disponibles.
Si se ejecuta Push, Git envía los commits locales pendientes al remoto.
Si se usa Sync Changes, VS Code coordina el proceso de traer y enviar cambios desde la interfaz.

Comprender esta mecánica evita un error muy habitual: creer que hacer commit ya equivale a “subir a GitHub”. No es así. El commit registra el cambio localmente; la sincronización es un paso aparte.

Cuándo usar cada opción¶

Opción	Cuándo usarla	Qué efecto tiene
Commit	Cuando el cambio ya está listo para registrarse localmente	Guarda el cambio en el historial local.
Push	Cuando se desea enviar commits locales a GitHub	Publica en el remoto los commits pendientes.
Pull	Cuando se necesita actualizar la copia local con lo que ya existe en el remoto	Trae cambios remotos al entorno local.
Sync Changes	Cuando se quiere sincronizar desde la interfaz de forma rápida	Coordina traer y enviar cambios.
Publish to GitHub	Cuando el repositorio local aún no tiene remoto	Crea y publica el repositorio remoto.

Ejemplo guiado: sincronización completa del proyecto¶

Imagina que el lector ya creó un commit local con mejoras en README.md, index.html y css/estilos.css.

Paso a paso:

Abre Source Control.
Verifica que no haya cambios pendientes que deban revisarse antes de sincronizar.
Usa Sync Changes o, si prefieres una acción explícita, selecciona Push desde el menú de opciones.
Espera a que VS Code complete la operación.
Abre el repositorio en GitHub y confirma que el commit aparezca en el historial remoto.

Esta última verificación es muy importante. No basta con asumir que el proceso terminó; conviene comprobar directamente en GitHub que el commit y sus archivos ya son visibles en el repositorio remoto.

Error común: sincronizar sin revisar cambios¶

Error común

Enviar cambios al remoto sin haber revisado primero el diff de los archivos. La sincronización no corrige errores; solo los hace visibles también en GitHub.

Diagrama: integración VS Code → Git → GitHub¶

La integración entre editor, repositorio local y plataforma remota puede entenderse mejor con el siguiente flujo.

flowchart LR
    A[Editar archivos en VS Code] --> B[Git detecta cambios locales]
    B --> C[Preparar archivos en Source Control]
    C --> D[Crear commit local]
    D --> E[Push o Sync Changes]
    E --> F[Repositorio remoto en GitHub]

En este recorrido, VS Code actúa como interfaz de trabajo, Git como motor de control de versiones local y GitHub como destino remoto de publicación y respaldo. El lector no está “guardando en la nube” directamente desde el editor; primero trabaja localmente y luego sincroniza con el remoto.

Conclusión de la sección¶

Sincronizar con GitHub desde VS Code es sencillo cuando se entiende que Commit, Push, Pull y Sync Changes son operaciones distintas dentro del mismo flujo. La interfaz acelera el proceso, pero la responsabilidad profesional sigue siendo revisar antes de publicar y verificar después en el repositorio remoto.

5.7 Explorando el historial¶

Revisar el historial permite comprender cómo ha evolucionado el proyecto con el paso del tiempo. VS Code incorpora funciones para consultar commits recientes y navegar por cambios anteriores desde una experiencia visual integrada. Esto resulta muy útil en un proyecto en crecimiento, porque ayuda a responder preguntas como: qué se cambió, cuándo se cambió y qué archivo fue afectado.

Historial básico¶

La documentación oficial de VS Code indica que el entorno incluye herramientas como el Source Control Graph, que ofrece una representación visual del historial de commits, y la Timeline view, que muestra la evolución de un archivo específico. En la guía rápida también se menciona el acceso al historial después de realizar commits desde la vista de control de versiones.

Para el lector, lo importante en esta etapa es entender que el historial no es una lista ornamental. Es un registro navegable del trabajo realizado, útil tanto para revisar avances recientes como para confirmar que un commit realmente se creó y quedó en la secuencia del proyecto.

Cambios recientes¶

Consultar los cambios recientes sirve para validar qué acaba de hacerse. Después de crear un commit desde VS Code, puede revisarse el historial para confirmar que el mensaje sea correcto y que la nueva confirmación esté presente donde corresponde.

En el proyecto del libro, esto podría utilizarse para verificar que una corrección de estilos o una mejora del contenido descriptivo quedó registrada con el mensaje esperado. Esa comprobación es especialmente valiosa cuando se hacen varios commits durante la misma jornada.

Navegación entre versiones¶

Explorar el historial también ayuda a navegar entre versiones de un mismo archivo. La documentación oficial explica que la Timeline view permite ver cómo ha evolucionado un archivo y filtrar eventos relacionados con commits de Git. Esto ofrece un punto de entrada muy práctico para revisar la historia de archivos concretos sin tener que inspeccionar todo el repositorio.

Aunque en este capítulo todavía no se trabajará con restauraciones avanzadas, sí es útil que el lector se familiarice con la idea de que cada commit crea un punto consultable del pasado. Gracias a eso, la evolución del proyecto puede revisarse con criterio, no solo recordarse de memoria.

Extensiones populares¶

VS Code permite ampliar la exploración del historial mediante extensiones. La propia documentación señala que ciertas funciones relacionadas con GitHub, como la gestión de pull requests e issues, se integran mediante extensiones específicas. Además, en el ecosistema de VS Code existen herramientas muy conocidas para enriquecer la visualización del historial.

Sin profundizar todavía, conviene mencionar que muchos desarrolladores utilizan extensiones para:

Ver anotaciones de autoría por línea.
Explorar commits con más contexto.
Comparar revisiones anteriores con mayor comodidad.
Navegar el historial de archivos de forma más detallada.

En este capítulo basta con saber que esas extensiones existen y que pueden ampliar el entorno, pero el dominio de la base integrada de VS Code debe venir primero.

Nota

Antes de instalar extensiones para “hacer más fácil” Git, conviene dominar el comportamiento nativo de VS Code. Así será más sencillo entender qué aporta realmente cada herramienta adicional.

Ejemplo guiado: revisar historial del proyecto¶

Crea uno o dos commits en el repositorio del libro siguiendo el flujo de las secciones anteriores.
Abre la vista o herramienta de historial disponible en tu instalación de VS Code, como el gráfico de control de código fuente o la línea de tiempo del archivo.
Confirma que el commit más reciente aparece con el mensaje que escribiste.
Selecciona un archivo que hayas modificado, por ejemplo README.md, y revisa su evolución mediante la línea de tiempo.
Observa cómo el historial se convierte en una narración técnica del proyecto: cada commit representa una decisión concreta.

Curiosidad sobre los commits¶

¿Sabías que...?

Cada commit tiene un identificador único, llamado SHA o hash, que permite localizarlo con precisión dentro del historial del proyecto. Aunque la interfaz muestre mensajes legibles, Git distingue internamente cada commit por ese identificador.

Conclusión de la sección¶

Explorar el historial desde VS Code ayuda a transformar los commits en una herramienta de lectura del proyecto, no solo de almacenamiento. Cuanto más claro sea el historial, más fácil será entender la evolución del repositorio y trabajar con seguridad sobre versiones recientes.

5.8 Flujo de trabajo recomendado¶

Llegados a este punto, ya se cuenta con todos los elementos necesarios para realizar un flujo de trabajo diario profesional desde Visual Studio Code sin abandonar la lógica de Git. La clave está en repetir una secuencia simple, consciente y consistente: modificar, revisar, preparar, confirmar, sincronizar y verificar.

El objetivo de este flujo no es solo “guardar cambios”, sino construir un historial limpio y mantener el repositorio remoto actualizado sin arrastrar errores innecesarios. Cuando este ciclo se vuelve hábito, la calidad del trabajo mejora de forma visible.

Flujo profesional diario¶

El flujo recomendado para este capítulo es el siguiente:

Modificar archivo

↓

Revisar cambios

↓

Preparar archivos

↓

Commit

↓

Push

↓

Verificar GitHub

Cada etapa cumple una función distinta. Saltarse una de ellas suele introducir errores: si no se revisa, se confirma a ciegas; si no se prepara con criterio, el commit mezcla tareas; si no se hace push, GitHub no mostrará los avances.

Diagrama: flujo de trabajo diario con VS Code¶

El siguiente diagrama resume ese recorrido de forma visual.

flowchart TD
    A[Modificar archivo] --> B[Revisar cambios en Source Control]
    B --> C[Preparar archivos correctos]
    C --> D[Escribir mensaje de commit]
    D --> E[Crear commit local]
    E --> F[Push o Sync Changes]
    F --> G[Verificar cambios en GitHub]

Este flujo convierte a VS Code en el punto central de trabajo diario. El editor se usa para modificar y revisar, Git para registrar la historia local y GitHub para reflejar el estado remoto del proyecto.

Explicación paso a paso del ciclo¶

1. Modificar archivo¶

Aquí ocurre el trabajo real de desarrollo. En el contexto del libro, esto puede significar ajustar un archivo HTML, mejorar estilos CSS, corregir un texto del README.md o refinar partes del proyecto que vienen construyéndose desde el Capítulo 2.

2. Revisar cambios¶

Antes de preparar nada, se abre Source Control y se inspeccionan los archivos afectados. Después se revisa el diff de cada archivo importante para confirmar que los cambios son correctos y que no se modificó nada por accidente.

3. Preparar archivos¶

Se agregan al área de preparación únicamente los archivos que pertenecen a la misma mejora o corrección. Esta etapa define qué entrará en el commit y qué quedará pendiente para más adelante.

4. Commit¶

Se escribe un mensaje claro y se crea el commit local con los archivos preparados. En este punto el cambio ya forma parte del historial del repositorio, pero todavía no aparece en GitHub.

5. Push¶

Se envían los commits locales al remoto mediante Push o Sync Changes. Solo después de esta etapa el cambio queda disponible en GitHub.

6. Verificar GitHub¶

Finalmente, se abre el repositorio remoto en GitHub para confirmar que el commit, los archivos y el contenido publicado coinciden con lo esperado. Esta verificación cierra el ciclo con una evidencia visible de que la sincronización salió bien.

Diagrama: ciclo completo de edición y sincronización¶

El ciclo diario no ocurre una sola vez. Se repite muchas veces durante el desarrollo del proyecto.

flowchart LR
    A[Editar] --> B[Revisar]
    B --> C[Preparar]
    C --> D[Commit]
    D --> E[Push]
    E --> F[Verificar en GitHub]
    F --> A

La naturaleza cíclica del proceso explica por qué conviene hacer commits pequeños y frecuentes. Cuanto más corto sea cada ciclo, más fácil será detectar errores, mantener claridad en el historial y evitar acumulaciones difíciles de revisar.

Interfaz gráfica o terminal dentro del flujo¶

Este flujo puede ejecutarse casi por completo desde la interfaz gráfica de VS Code, pero no deja de ser válido combinarlo con la terminal cuando convenga. Por ejemplo:

Revisar visualmente en Source Control.
Confirmar con git status en la terminal para validar el estado exacto.
Hacer commit desde la interfaz.
Usar push desde el panel o desde la terminal según preferencia.

Ese equilibrio es una señal de madurez técnica. La herramienta cambia; la disciplina del flujo permanece.

Práctica guiada del capítulo¶

Sigue esta práctica completa usando el mismo repositorio del libro:

Abre el proyecto en VS Code.
Modifica varios archivos ya existentes del proyecto, por ejemplo README.md, index.html y css/estilos.css.
Guarda los cambios.
Abre Source Control y observa los archivos modificados y sus indicadores visuales.
Revisa cada archivo en el diff editor para identificar líneas agregadas, eliminadas o modificadas.
Prepara los archivos que sí pertenecen al mismo objetivo de trabajo usando el icono +.
Escribe un mensaje de commit claro y crea el commit desde la interfaz.
Usa Sync Changes o Push para sincronizar con GitHub.
Abre el repositorio remoto y confirma que los cambios aparecen correctamente en GitHub.

Errores comunes dentro del flujo¶

Error común

Hacer varios cambios distintos durante horas y luego intentar confirmarlos todos en un único commit. Eso dificulta revisar, describir y comprender lo realizado.

Consejo

Si una modificación responde a una idea concreta, intenta cerrar el ciclo completo antes de comenzar una tarea diferente: revisar, preparar, commit y push. El historial lo agradecerá.

Diagrama: integración operativa entre VS Code, Git y GitHub¶

Este tercer diagrama resume cómo interactúan las tres piezas principales del entorno.

flowchart TD
    A[VS Code] --> B[Editar archivos]
    B --> C[Source Control]
    C --> D[Área de preparación de Git]
    D --> E[Commit local en Git]
    E --> F[Push]
    F --> G[GitHub]

VS Code proporciona la experiencia visual de trabajo, Git mantiene el control de versiones local y GitHub actúa como plataforma remota de sincronización y consulta. Entender esa separación ayuda a evitar confusiones entre guardar, confirmar y publicar.

Conclusión de la sección¶

El flujo recomendado con VS Code convierte el uso de Git en una rutina clara y sostenible: modificar, revisar, preparar, confirmar, sincronizar y verificar. Repetir este ciclo con disciplina produce repositorios más limpios, commits más útiles y una relación mucho más profesional con GitHub.

Cierre del capítulo¶

Visual Studio Code ofrece una integración muy práctica con Git y GitHub, pero su verdadero valor aparece cuando se utiliza con criterio técnico. A lo largo de este capítulo se vio cómo el panel Source Control permite reconocer el estado del repositorio, visualizar cambios, preparar archivos, crear commits, consultar el historial y sincronizar con el remoto sin abandonar el editor.

También quedó claro que la interfaz gráfica no reemplaza la comprensión de Git. Detrás de cada clic siguen existiendo operaciones reales como git add, git commit, git pull y git push. Por eso, el dominio profesional consiste en interpretar correctamente la interfaz, relacionarla con los conceptos fundamentales y elegir cuándo conviene trabajar visualmente y cuándo conviene acudir a la terminal.

Con este capítulo, el lector ya cuenta con un flujo práctico y sólido para trabajar diariamente con el repositorio del libro desde VS Code. En adelante, esa combinación entre claridad visual y comprensión técnica será una base muy valiosa para avanzar hacia flujos más completos dentro del ecosistema de Git y GitHub.

Notas al pie¶

Para profundizar¶

Git. git-add Documentation. https://git-scm.com/docs/git-add
Git. git-commit Documentation. https://git-scm.com/docs/git-commit
Git Book. Git in Visual Studio Code. https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio-Code
Visual Studio Code. Source Control in VS Code. https://code.visualstudio.com/docs/sourcecontrol/overview

Visual Studio Code. Quickstart: use source control in VS Code. https://code.visualstudio.com/docs/sourcecontrol/quickstart ↩
GitHub Docs. About commits. https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/about-commits ↩