¿Estás usando GitHub sin saber bien lo que haces?
Usarlo a ciegas es la receta perfecta para romper algo.
En GitHub solo hay tres botones verdes.
Y solo hay un lugar donde mirar antes de presionarlos.
Este artículo te muestra exactamente dónde mirar y qué presionar en la pantalla de GitHub, todo marcado con recuadros rojos.
Conectar, enviar, revisar el diff, hacer merge y revertir.
Vamos a recorrer este ciclo completo con 10 capturas de pantalla reales.
La IA se encarga de escribir.
Tú solo miras y presionas.
Te voy a explicar los términos difíciles de forma sencilla a medida que aparezcan.
※ Las pantallas y especificaciones de GitHub de este artículo fueron verificadas en octubre de 2026. Las interfaces pueden cambiar.
Capítulo 1: Conectarse a GitHub | Crear un repositorio y subir registros locales
La interfaz de GitHub está en inglés.
Pero los lugares que debes presionar siempre son los mismos.
Los recuadros rojos en la pantalla te muestran dónde mirar y dónde hacer clic.
En este capítulo, solo hay un botón verde que presionar.
Primero, crea un repositorio.
Un repositorio es como un casillero donde guardas tus registros de Git en internet.
Hablé sobre lo que va dentro del casillero y cuatro términos clave en mi publicación anterior.
【Con diagramas】Git explicado para estudiantes de secundaria
https://x.com/dan_pro_man/status/2107224533099069671?s=20
Aunque no la hayas leído, puedes completar el ciclo entero solo con este artículo.
Inicia sesión en GitHub y selecciona "New repository" desde el ícono "+" en la esquina superior derecha.
Si abres https://github.com/new, llegarás a la misma pantalla.
Lo único que necesitas ingresar es un nombre.
Escribe un nombre alfanumérico en "Repository name".
"git-practice" funciona perfecto.
Selecciona "Private" debajo de "Choose visibility".
Esto significa que no será público.
Deja desactivado el interruptor de "Add README" por ahora.
Si ya tienes registros locales, es más fácil conectarte si creas un repositorio vacío.
Presiona el botón verde "Create repository" en la parte inferior.
La pantalla que aparece justo después de presionarlo es la parte más importante de este capítulo.
Cerca de la parte inferior, hay un encabezado que dice: "…or push an existing repository from the command line".
Las tres líneas debajo de ese texto son los comandos que usaremos hoy.
Las siete líneas de arriba son para quienes todavía no tienen registros locales, así que puedes ignorarlas.
Esto es lo que significan las tres líneas:
Línea 1: Le dices a tu registro local cuál es la dirección de este casillero.
Línea 2: Alineas el nombre de la rama principal a "main".
Línea 3: Guardas la rama main en el casillero.
Copia la dirección (recuadro rojo) de esta pantalla y envíala a la IA en una sola línea.
1Sube los registros de esta carpeta a https://github.com/nombre-de-cuenta/git-practice
Claude Code escribirá esas tres líneas por su cuenta.
Claude Code es una IA que ejecuta tareas en tu computadora siguiendo instrucciones.
En mi manual de instrucciones, exijo confirmación antes de hacer push.
Hacer push es la operación de guardar los registros locales en el casillero.
Por eso, se detiene aquí un momento.
Responde "Yes" y luego actualiza la pantalla del navegador.
Donde estaban los tres comandos, ahora verás tus archivos locales alineados. Al lado de cada uno está el mensaje de commit.
Esta es la señal de que estás "conectado".
Aquí quiero que notes algo.
El texto "main" encima de la lista de archivos.
Indica qué marcador estás viendo actualmente dentro del casillero.
Un marcador es una rama (branch).
Señala en qué columna estás apilando los registros.
De ahora en adelante, no toques este "main" directamente.
Al principio, yo tampoco le prestaba mucha atención a esto.
Trabajaba en main y perdía tiempo buscando cómo volver atrás.
Cuando las conexiones fallan, casi siempre es por la dirección.
Falta el ".git" al final.
El nombre de la cuenta está mal escrito.
Si ves "not found", vuelve a copiar la dirección de la Imagen ②.
A esta altura, tus registros locales ya están conectados a GitHub. Lo siguiente es el ciclo diario de hacer merges mediante Pull Requests.
**
Capítulo 2: Hacer merge mediante Pull Request | Enviar el trabajo de la IA, revisar el diff y presionar
Aquí empieza el ciclo diario.
Un Pull Request es un envío que básicamente dice: "Por favor, integra esto".
En este capítulo, hay tres botones verdes que presionar.
La IA escribe.
Tu único trabajo es mirar y presionar.
Primero, envíale una línea a la IA.
1Crea una nueva rama, agrega 3 líneas de uso al README, haz commit y súbelo a GitHub
El README es el primer archivo donde describes el repositorio.
Claude Code crea una rama.
Modifica el archivo y hace commit.
Finalmente, se detiene antes de hacer push y te pregunta.
Responde "Yes" y luego abre el casillero en tu navegador.
Aparecerá un banner amarillo en la parte superior.
Te avisa: "Acabo de guardar esta rama".
Presiona el botón verde "Compare & pull request" a la derecha.
Este es el 'Envío'.
Es como entregarle un cuaderno borrador al profesor.
Solo enviarlo no copia nada a la versión final.
La copia ocurre después de la revisión.
Hay tres lugares que debes revisar en la pantalla de envío.
1.°: La flecha en la parte superior.
"base: main" y "compare: work-branch"
Esto muestra desde dónde y hacia dónde se hará el merge.
Solo confirma que el lado izquierdo sea main.
2.°: El título en "Add a title".
Si lo genera la IA, incluirá un resumen de los cambios.
Si lo envías manualmente, el mensaje de commit viene precargado.
Si lo envías tú, escribe "qué se hizo" en una sola línea.
3.°: El botón verde "Create pull request".
Al presionarlo, aceptas el envío.
Después de enviarlo, se requiere acción humana.
Aparecen cuatro pestañas en la parte superior de la pantalla.
Mira solo la última pestaña a la derecha: "Files changed".
Significa archivos modificados.
Las líneas verdes son agregados.
Las líneas rojas son eliminaciones.
Esto es el diff.
Si las 3 líneas que pediste están en verde, pasa la prueba.
En la pantalla de ejemplo, también se agregaron encabezados y líneas en blanco, sumando 6 líneas verdes.
Si hay líneas rojas que no pediste, no hagas merge.
En la pantalla de ejemplo, hay 1 línea roja.
Una línea de nota desapareció de "Items placed".
Si no pediste esto, detente aquí.
Pregúntale a la IA: "¿Por qué borraste esta línea roja?".
Estos son los 30 segundos más críticos cuando delegas trabajo a la IA.
Antes, cuando solo ver notificaciones de revisión me revolvía el estómago, solía presionar sin revisar esto.
Ahora, primero cuento las líneas rojas.
Si hay aunque sea una línea roja que no pedí, me detengo.
Si el diff no tiene problemas, vuelve a "Conversation".
Cerca de la parte inferior, hay un botón verde "Merge pull request".
Si arriba dice "No conflicts with base branch", puedes hacer merge directamente.
Al presionarlo, cambia a "Confirm merge".
Vuélvelo a presionar.
Ahora, los registros de la rama de trabajo se integraron a main.
El color cambia a morado y muestra "Merged".
Abajo aparece un cuadro que dice "Pull request successfully merged and closed".
A su derecha está "Delete branch".
Siéntete libre de presionarlo.
Solo desaparece el "marcador" de la rama de trabajo dentro del casillero.
Como los registros ya se integraron a main, no se pierde nada.
Por último, actualiza tu entorno local.
Dile a la IA: "Cambia a main y trae lo último de GitHub".
Con eso completas un ciclo.
Empieza la siguiente tarea desde una rama nueva.
No trabajes en main.
A esta altura, ya completaste el ciclo de enviar, revisar el diff y hacer merge. Lo siguiente es Revert, el botón para deshacer errores después de un merge.
**
Capítulo 3: Revertir | Deshacer errores después de un merge con un solo botón
A veces notas errores recién después de hacer merge.
En Git, "deshaces" los registros guardados sin borrarlos.
La pantalla de GitHub tiene un botón para esto.
Se llama "Revert".
Vuelve a abrir el Pull Request que acabas de integrar.
Habrá una línea que dice "merged commit … into main".
En el extremo derecho de esa línea está "Revert".
¿Qué pasa cuando lo presionas?
Los registros no se borran.
Se crea un nuevo Pull Request con los cambios opuestos.
Según la documentación oficial, el merge ocurre cuando integras este nuevo Pull Request.
Así que revertir sigue el mismo ciclo del Capítulo 2.
Revisa el diff y presiona el botón verde.
En lugar de borrar, se agrega un registro de "revertido".
Si le pides a la IA, dile: "Deshaz el Pull Request que acabo de integrar".
Claude Code hace lo mismo con git revert.
Hay otra pantalla con la que te podrías cruzar.
"This branch has conflicts that must be resolved".
Esto es un conflicto.
Ocurre cuando la misma línea se modificó de forma distinta en main y en la rama de trabajo.
El botón verde se vuelve gris y no se puede presionar.
No intentes arreglarlo en la pantalla; envíale una línea a la IA.
1Trae main y muéstrame ambas versiones de las partes en conflicto
Tú decides cuál conservar.
Cuando la IA lo arregle y lo vuelva a subir, el botón verde regresará.
Los conflictos no son fracasos.
Simplemente revelan el hecho de que la misma línea se editó dos veces.
Por último, algo que no aparece en pantalla.
Las claves.
Los archivos que contienen contraseñas o API keys nunca deben subirse a GitHub.
Incluso si usas Revert, una vez que una clave se sube, se considera comprometida y hay que regenerarla.
Antes de subir nada, dile a la IA: "Excluye .env de los registros".
En mi propio trabajo, escribo configuraciones de AWS en archivos de texto y sigo este mismo ciclo.
Las configuraciones que se integran sin revisar diffs se ejecutan directo en producción.
Por eso, no le delego a la IA esos 30 segundos críticos antes de presionar.
Los humanos presionamos todos los botones de la pantalla.
Aunque amplíe lo que maneja la IA, esta regla no cambia.
Con esto, el ciclo completo de conectar, enviar, hacer merge y revertir está terminado.
Para terminar, te dejo material listo para usar.
Detallé los pasos para completar un ciclo en la pantalla de GitHub.
Empaqueté las pantallas y prompts de este artículo en formatos listos para usar.
- Póster de traducción de pantallas de GitHub (9 pantallas, 69 términos)
- Mapa de recuperación para cuando la IA rompe algo (6 escenarios)
- 7 prompts para un ciclo completo
- Hoja de checklist previa al merge (8 puntos)
Todo entregado junto en un cuadernillo PDF de 15 páginas.
Solo con esto, puedes empezar a completar ciclos hoy mismo.
Para recibirlo, únete al Open Chat de abajo.
Sigue las instrucciones después de unirte, envía "Submit" y te llegará automáticamente.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
Resumen: Completa un solo ciclo hoy
No pongas el trabajo de la IA directamente en main.
Envíalo desde una rama de trabajo, revisa el diff y presiona los botones verdes.
Hubo tres botones verdes que presionar en un ciclo.
El día que presioné Revert por primera vez, entendí que los registros no se borran.
Después de eso, dejé de tener miedo de tocar cosas.
No necesitas hacerlo todo de golpe.
Hoy, solo hay una cosa por hacer.
Abre el repositorio que creaste en el Capítulo 1 y envíale una línea a la IA.
Crea una nueva rama, agrega 1 línea al README y súbelo a GitHub
Cuando aparezca el banner amarillo, presiona el botón verde y abre "Files changed".
Si solo hay una línea verde, pasa la prueba.
Mira esa línea con tus propios ojos antes de hacer merge.
Ese es el primer paso para ampliar lo que puedes delegarle a la IA.
Para los ingenieros mayores de 30, ganar no se trata de volumen de trabajo, sino de diseño.
En lugar de reaprender herramientas cada vez que se actualizan, es más rápido definir hasta dónde llegar.
AWS y la IA evolucionan rapidísimo.
Ver los logs de personas probando en trabajo real es más rápido que intentar mantenerse al día solo.
En mi práctica de IA × Ingeniería, no solo dejo registros de éxitos, sino también de cosas rotas y excluidas.
¡Sígueme para no perderte los próximos aprendizajes! @dan_pro_man
