Guía de inglés para developers
Mensajes de commit y comentarios de code review en inglés
July 27, 2026
Escribir un buen mensaje de commit es una habilidad de comunicación, no solo una regla de sintaxis. Esta guía cubre las convenciones que hacen legibles los commits, los comentarios de code review que son claros y profesionales, y las frases que mantienen el feedback constructivo incluso cuando se requiere un cambio.
Convenciones de mensajes de commit
El modo imperativo, la regla de los 50 caracteres y los prefijos de tipo más comunes. Cada prefijo se muestra con un ejemplo débil y una versión más sólida.
Usa el modo imperativo
Los mensajes de commit en Git usan el modo imperativo: la primera línea se lee como si estuvieras dando una instrucción. Piensa en completar la frase 'Si se aplica, este commit va a...'
“Added dark mode toggle”
“Adding dark mode toggle”
“Add dark mode toggle”
Mantén el asunto en menos de 50 caracteres
GitHub trunca los asuntos que superan los 72 caracteres. 50 es el objetivo práctico porque cabe en la mayoría de las interfaces sin cortarse. Si no puedes resumir el cambio en 50 caracteres, probablemente el commit hace demasiadas cosas.
feat:
Una nueva característica visible para el usuario o consumidor de la API. Es el prefijo más importante: marca trabajo que agrega valor.
feat: stuff
feat: add dark mode toggle to user settings
fix:
Una corrección de error. Describe qué estaba roto, no solo que algo se corrigió. El lector quiere saber qué comportamiento cambió.
fix: bug fix
fix: prevent login redirect loop when session expires mid-request
docs:
Solo cambios de documentación: README, comentarios inline, docs de API. No se modifica código de producción.
docs: update readme
docs: add setup instructions for M1 Mac local environment
chore:
Tareas de mantenimiento que no afectan el comportamiento de la app: actualizaciones de dependencias, config de build, cambios en CI.
chore: update things
chore: upgrade eslint to v9 and fix resulting lint warnings
refactor:
Reestructuración de código sin cambio de comportamiento. Los tests siguen pasando. La salida es la misma; solo mejoró la estructura interna.
refactor: clean up
refactor: extract email validation into a standalone utility function
test:
Agregar o actualizar tests. No se modifica código de producción. Un buen prefijo para usar cuando se mejora la cobertura después de un reporte de error.
test: add tests
test: add edge cases for token refresh handler — expired and malformed tokens
Cuándo escribir el cuerpo de un commit
La primera línea no siempre es suficiente. Aquí te mostramos cuándo y cómo escribir el cuerpo.
El cuerpo del commit
Agrega un cuerpo cuando el porqué no es obvio a partir del asunto. Deja una línea en blanco entre el asunto y el cuerpo. Envuelve las líneas a 72 caracteres. Explica qué cambió y por qué, no cómo: el diff ya muestra el cómo.
feat: add rate limiting to the login endpoint Without rate limiting, an attacker can try thousands of passwords per second against any account. This adds a 5-request-per-minute limit using the existing Redis cache. Refs: #412
Etiquetas de code review: nit, required, LGTM y más
Las etiquetas que usan los reviewers para clasificar sus comentarios. Conocerlas te evita tratar cada comentario como un bloqueante.
nit:
No bloqueanteAbreviación de 'nitpick' (queja menor). Un pequeño problema de estilo o redacción: no está mal, es solo una preferencia personal. El autor puede ignorarlo sin bloquear el merge.
“nit: this variable name could be `userCount` to match the rest of the file.”
suggestion:
No bloqueanteUna mejora concreta que el reviewer cree que haría el código mejor. Se puede tomar o no: no es obligatoria antes de mergear.
“suggestion: you could extract this logic into a helper function to avoid repeating it in the next section.”
question:
No bloqueanteCuriosidad genuina, no crítica. El reviewer quiere entender una decisión, no cuestionarla. Debe sentirse seguro responder de cualquier manera.
“question: why do we use a Map here instead of a plain object? Is there a performance reason?”
required: / blocker:
BloqueanteEsto debe corregirse antes de que el PR pueda mergear. Un bug, un problema de seguridad o una violación del contrato del equipo. Siempre explica por qué.
“required: this endpoint has no authentication check — any unauthenticated user can access it.”
LGTM
No bloqueanteLooks Good To Me (Se ve bien para mí). Aprobación. También puedes escribir 'LGTM with nits' para aprobar dejando comentarios opcionales, o 'ship it' con el mismo efecto.
“LGTM! Nice cleanup on the error handling.”
Educado vs. vago: cómo dar feedback claro
El feedback directo es mejor que el vago. Pero hay una diferencia entre directo y brusco. Estos patrones te muestran cómo ser claro y profesional al mismo tiempo.
Situación
Señalar un bug (bloqueante)
Débil
“This is wrong. It will break in production.”
Más sólido
“required: this could cause a race condition if two requests hit this endpoint at the same time — consider using a mutex or moving the check inside the transaction. What do you think?”
Situación
Sugerir un mejor enfoque (no bloqueante)
Débil
“You should use a Map here.”
Más sólido
“suggestion: a Map might work better here since you are doing frequent lookups by key — it would keep the lookup O(1) instead of O(n). Happy to discuss if there is a reason you went with an array.”
Situación
Preguntar sobre una decisión de diseño
Débil
“Why did you do it this way?”
Más sólido
“question: I see we are calling this API on every render — is that intentional, or would it make sense to cache the result? Just want to make sure I understand the tradeoff.”
Situación
Señalar un problema de nombres (nit)
Débil
“Bad variable name.”
Más sólido
“nit: `data` is a bit generic here — something like `userList` or `activeUsers` might make this easier to follow at a glance. Totally optional though.”
Aceptar feedback con buena actitud
Cómo responder a un comentario de review en inglés: reconocer una corrección, disentir con respeto y hacer preguntas de seguimiento.
“Good catch, fixed in the latest push.”
Cuándo usarlo
Reconocer un bug que encontró el reviewer y confirmar que lo corregiste.
“You are right, updated.”
Cuándo usarlo
Breve y profesional. Úsalo para correcciones pequeñas donde no se necesita explicación.
“Makes sense, I went with your suggestion in the latest commit.”
Cuándo usarlo
Confirmar que adoptaste la sugerencia del reviewer e indicar dónde.
“I see the issue, but I kept this approach because [reason]. Let me know if that works for you.”
Cuándo usarlo
Disentir con respeto. Explicas tu razonamiento e invitas a continuar la conversación.
“Thanks for flagging this! I was not aware of that constraint.”
Cuándo usarlo
El reviewer señaló una regla, contrato o riesgo que no conocías.
Puntos clave
Los asuntos de commit usan el modo imperativo: 'Add feature', no 'Added feature' ni 'Adding feature'.
Mantén el asunto en menos de 50 caracteres. Si no puedes, el commit probablemente hace demasiadas cosas.
Usa prefijos de tipo (feat, fix, docs, chore, refactor, test) para que el historial sea fácil de escanear.
En code reviews: nit = opcional, suggestion = no bloqueante, question = curiosidad genuina, required/blocker = debe corregirse.
LGTM significa aprobado. 'LGTM with nits' significa aprobado con comentarios opcionales.
Enmarca los blockers como explicaciones, no como órdenes: 'esto podría causar X, considera Y' en lugar de 'cambia esto a Y'.
Cuando aceptas feedback, confirma la corrección: 'Good catch, fixed in the latest push.'
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratisRelated articles
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.