Control de versiones de diagramas de flujo: cómo funciona en realidad
Qué significa el control de versiones de un diagrama de flujo, por qué exportarlo a PDF o PNG tira su estructura real, y cómo el registro de cambios y Comparar versiones de QueryChart rastrean cada caja, conector y etiqueta.
El control de versiones de un diagrama de flujo es un registro de cada estado pasado de las cajas, conectores y etiquetas de un diagrama (no del archivo que lo contiene) para que un lector pueda ver exactamente qué cambió, quién lo cambió y volver a cualquier estado anterior.
En resumen
- Un nombre de archivo como «v3_FINAL_revisado(2)» es una suposición, no un historial de versiones.
- La exportación a PDF o PNG conserva una imagen del diagrama de flujo, no su estructura editable.
- El versionado de archivos del almacenamiento en la nube rastrea el archivo, no las cajas y conectores de dentro.
- El control de versiones real de un diagrama de flujo diferencia cambios de caja, conector y etiqueta entre dos estados guardados cualesquiera.
- El registro de cambios y Comparar versiones de QueryChart hacen esto automáticamente en cualquier diagrama, gratis: ver /features/version-control.
Un nombre de archivo no es un historial de revisiones
En algún sitio de una unidad compartida hay ahora mismo un Mapa_Proceso_v3_FINAL_revisado(2).vsdx, al lado de un Mapa_Proceso_v3_FINAL_revisado.vsdx y un Mapa_Proceso_v2.pdf que un interesado todavía tiene adjunto a un hilo de correo antiguo. Entre los tres no hay registro de qué caja se movió, qué rama de decisión se reetiquetó, quién hizo cada cambio, ni si alguien llegó a dar el visto bueno: solo un nombre de archivo haciendo el trabajo que se supone que hace un historial de versiones.
Exportar un diagrama de flujo a una imagen o a un PDF para archivarlo sí captura su aspecto, pero tira lo único que necesita un lector posterior: la estructura editable de debajo. Un PNG no se puede comparar contra otro PNG para mostrar que una caja de decisión ganó una tercera rama: alguien tiene que mirar dos imágenes a ojo y adivinar. El propio «historial de versiones» de una unidad en la nube tampoco resuelve esto: versiona el archivo, no el diagrama de dentro. Puede devolver el .vsdx o el .pptx de ayer, pero no tiene ni idea de que una caja concreta cambió de carril o de que la etiqueta de un conector pasó de «Escalar» a «Aprobar automáticamente» entre dos instantáneas.
Una herramienta de diagramación con control de versiones real hace tres cosas que un nombre de archivo y una unidad compartida no pueden: te deja navegar cada revisión pasada del propio diagrama, muestra exactamente qué caja, conector o etiqueta cambió entre dos cualesquiera de ellas, y restaura un estado antiguo sin perder el trabajo hecho desde entonces. QueryChart hace esto en cualquier diagrama, en vivo, automáticamente y gratis: el registro de cambios anota cada edición con quién la hizo y qué campo tocó, y Comparar versiones pone dos versiones guardadas cualesquiera una junto a otra. El mecanismo completo está en /features/version-control.
Esa distinción importa porque un diagrama de flujo no es el mismo objeto que el documento de proceso en el que puede estar incrustado. Esta página trata de versionar la estructura propia del diagrama (cajas, carriles, conectores) dentro de una herramienta construida para rastrear esa estructura. Si en cambio gestionas revisiones de un documento de proceso más largo que resulta que contiene un diagrama, la versión neutral respecto a la herramienta de este mismo problema está cubierta en /es/guides/control-de-versiones-para-documentacion-de-procesos.
Cómo se gana este documento su propio número de versión, fila a fila
El esquema de numeración de versiones de abajo es exactamente la disciplina que un propietario de documento aplica a mano (decimales para borradores, números enteros para aprobaciones), la misma distinción que el registro de cambios de QueryChart rastrea automáticamente para el propio diagrama, sin que nadie teclee un número.
El borrador coge un decimal, no una suposición
La fila de inicio es «Nuevo documento redactado», y la fila inmediatamente siguiente es «Asignar versión de borrador inicial 0.1»: el decimal identifica exactamente por cuántos ciclos de revisión ha pasado el borrador, antes incluso de que ocurran «Circular el borrador para revisión interna» y «El revisor evalúa el borrador».
Cada corrección sube el número, no las conjeturas
En «¿Se requieren cambios?» un Sí enruta a «Incrementar la versión menor» antes de que empiece «Corregir el borrador según los comentarios», así que un revisor que cita comentarios de un decimal concreto está nombrando un borrador exacto y localizable en lugar de un vago archivo «más reciente».
La aprobación es el único suceso que se gana un número entero
«Enviar el borrador final para aprobación» y «El aprobador revisa el borrador final» llevan a «¿Aprobado para emisión?»: solo la rama Aprobado llega a «Asignar versión mayor 1.0», así que nada anterior a ese punto, por muchos borradores decimales que haya atravesado, se confunde nunca con la versión 1.0.
La publicación actualiza el registro antes de que nadie lea
«Actualizar el registro del historial de versiones» se ejecuta antes de «Publicar la versión aprobada», y «Marcar la versión anterior como obsoleta» viene inmediatamente después, así que el registro con todos los números pasados, no solo el vigente, está actualizado antes de que un solo lector llegue a «El lector accede a la versión vigente».
Un cambio posterior reabre el registro, no lo sobrescribe
«¿Se solicita un cambio tras la publicación?» o bien devuelve el proceso a «Reabrir el documento en la siguiente versión» (reiniciando la cadena numerada en vez de editar el archivo vigente en su sitio) o termina en «La versión actual sigue en vigor», con cada número anterior todavía en el registro.
Cómo funciona
Deja de poner nombres de versión en el archivo
Retira por completo la convención «v3_FINAL_revisado(2)»: un decimal o un color tecleado en un nombre de archivo es una etiqueta que añadió alguien, no un registro de lo que cambió. Modela el diagrama de flujo en una herramienta que mantenga su propio historial de revisiones, y deja que el nombre del archivo vuelva a ser solo un nombre de archivo.
Dale a cada envío a revisión una versión nombrada
En QueryChart, enviar un diagrama a revisión guarda automáticamente una versión con nombre, y nunca se sobrescribe nada. Ese único hábito sustituye a todo el rastro de «Guardar como» de archivos duplicados, porque el estado anterior se conserva, se acuerde o no alguien de renombrar algo.
Abre el registro de cambios antes de preguntar qué cambió
El registro de cambios lista cada edición del diagrama, quién la hizo y a qué campo afectó, así que «qué cambió desde el martes» es desplazarse por una lista, no un ejercicio de memoria ni entrecerrar los ojos comparando dos imágenes exportadas.
Compara dos versiones en lugar de comparar dos exportaciones a ojo
Usa Comparar versiones para elegir dos versiones guardadas cualesquiera y ver la diferencia campo a campo: los cambios de caja, conector y etiqueta se señalan uno por uno como añadidos, eliminados o modificados, en lugar de dejar que un lector los detecte entre dos PDF aplanados.
Restaura en lugar de reconstruir de memoria
Si una revisión resulta estar mal, restaura la versión anterior en vez de redibujarla a mano desde una exportación antigua. La propia restauración se convierte en una nueva entrada del historial, así que no se pierde nada sobre el origen del borrador actual.
Mantén el diagrama como el maestro, no su exportación
Trata el PDF o el PNG que distribuyes como una instantánea para los lectores, nunca como el registro del que reconstruirías nada: el diagrama editable con su historial de versiones es la única copia que puede responder «cómo era esto en marzo», y la exportación no puede.
Errores que debes evitar
El «(2)» del nombre de archivo es la pista
Un número entre paréntesis añadido a un nombre de archivo ya versionado significa que dos personas editaron a la vez la misma copia «más reciente» sin ninguna forma de fusionarlas. La solución no es una convención de nombres mejor, es eliminar la necesidad de una: un diagrama, un historial, sin copias que colisionen.
Un PDF exportado que sobrevive al diagrama del que salió
Un PDF pegado en una pared o adjunto a un correo antiguo sigue circulando mucho después de que el diagrama del que se exportó haya avanzado, y nada en el propio PDF lo señala. Trata cada exportación como fechada en el momento en que se crea, y enlaza de vuelta al diagrama en vivo en lugar de volver a compartir el archivo.
Confundir el versionado de archivos con el versionado de diagramas
OneDrive, Google Drive y Dropbox pueden devolver el archivo de ayer, pero ninguno puede decirte que una caja de decisión ganó una rama o que la etiqueta de un conector cambió: versionan el contenedor, no su contenido. El historial propio de una herramienta de diagramación es el único sitio donde existe esa diferencia.
Restaurar en silencio en vez de dejarlo en el registro
Pegar el contenido de una exportación antigua de vuelta en el archivo actual borra el hecho de que se produjo una restauración. Una restauración que crea su propia entrada nueva y fechada (como hace la de QueryChart) mantiene visible para el siguiente lector el motivo de la reversión, en lugar de parecer que el diagrama siempre fue así.
Crea tu propio diagrama de flujo con control de versiones
Abre el ejemplo de numeración de versiones como diagrama propio y después envíalo a revisión una vez para ver aparecer automáticamente una versión con nombre, el registro de cambios y Comparar versiones.
Guías relacionadas
Preguntas frecuentes
¿Es el control de versiones de diagramas de flujo distinto del control de versiones de documentos?
No en principio (los dos significan mantener cada estado pasado de algo para poder ver qué cambió y volver a él), pero el «cambió» de un diagrama de flujo es estructural: qué caja se movió, qué conector se añadió, qué etiqueta se reformuló. Un proceso de control de versiones de documentos construido en torno a prosa y números de página no diferenciará una rama de decisión. Ver /es/guides/control-de-versiones-para-documentacion-de-procesos para la versión de este problema centrada en un documento de proceso completo en lugar de en un único diagrama.
¿Exportar un diagrama de flujo a PDF cuenta como control de versiones?
No: es una instantánea, no un historial. Un PDF captura un momento, pero no se puede comparar automáticamente contra otro PDF para mostrar qué cambió, no se puede editar y no lleva registro de quién hizo el cambio anterior ni por qué. Es útil para compartir una copia fija con un lector; no sustituye al historial de versiones propio del diagrama.
¿Cuál es la diferencia entre el registro de cambios y Comparar versiones en QueryChart?
El registro de cambios es la línea temporal: cada edición, quién la hizo y aproximadamente cuándo, leída de arriba abajo. Comparar versiones responde a una pregunta más concreta: elige dos versiones guardadas cualesquiera y ve la diferencia campo a campo entre ellas, caja por caja y conector por conector, en lugar de desplazarte por todo el registro para reconstruirla tú mismo.
¿Puedo restaurar una versión antigua de un diagrama de flujo sin perder el trabajo actual?
Sí: restaurar una versión anterior en QueryChart crea una versión nueva en lugar de eliminar las que vinieron después, así que el trabajo hecho desde entonces permanece en el historial aunque ya no sea el estado activo. Nada de una restauración es destructivo.
