Qué hace realmente marcar como duplicado
Dos issues de tu repositorio describen casi el mismo problema.
Uno ya está en proceso; el otro acaba de llegar de una persona que reporta por primera vez.
Ahora enfrentas una decisión de triage pequeña pero real: ¿clonas el issue original o marcas el nuevo como duplicado?
Las dos acciones están integradas en GitHub, pero hacen cosas muy distintas.
Clonar crea un issue nuevo con campos precargados.
Marcar como duplicado vincula dos issues existentes en la línea de tiempo.
Elegir mal puede dividir la conversación, confundir a quien reporta o perder contexto silenciosamente.
Esta guía explica qué hace cada acción, qué acceso necesitas y en qué situaciones conviene más una que la otra.
Cuando marcas un issue o pull request como duplicado, escribes “Duplicate of” seguido del número del issue o pull request en el cuerpo de un comentario nuevo.
GitHub entonces muestra un evento de línea de tiempo “marked as duplicate”, que agrupa issues similares y reduce carga innecesaria para mantenedores y colaboradores.
GitHub también ofrece respuestas guardadas llamadas “Duplicate issue” y “Duplicate pull request” si prefieres no escribir la frase cada vez.
Hay un requisito documentado que conviene conocer antes de intentarlo.
Para que aparezca el evento “marked as duplicate”, quien crea el comentario de referencia debe tener acceso de escritura al repositorio donde lo publica.
Si comentas sin ese acceso, la frase por sí sola no genera el evento en la línea de tiempo.
La acción también es reversible de forma documentada.
Puedes desmarcar issues y pull requests duplicados haciendo clic en Undo en la línea de tiempo.
Eso añade un nuevo evento que indica que el issue fue desmarcado, así el historial del comentario original sigue visible en lugar de desaparecer.
Qué hace realmente clonar un issue
Clonar es una herramienta distinta para un trabajo distinto.
GitHub la describe como una forma rápida de crear un issue similar: puedes clonar un issue abierto existente al mismo repositorio o a uno diferente.
El issue original queda sin cambios, y el nuevo recibe su propia URL y puede editarse antes de crearse.
Clonar tiene dos requisitos de acceso documentados.
Necesitas acceso de triage en el repositorio que contiene el issue original y en el repositorio de destino.
El repositorio de destino también debe permitir issues en blanco.