Control de versiones frente a control de cambios: cuál es la diferencia
El control de versiones rastrea qué revisión de un documento está vigente y qué cambió; el control de cambios decide si un cambio propuesto puede llegar a producirse y quién tiene que aprobarlo primero.
El control de versiones es el mecanismo que identifica y recuerda los estados sucesivos de un documento; el control de cambios es el proceso de gobierno que decide si un cambio está permitido antes de que se cree una versión nueva.
En resumen
- El control de versiones rastrea identidad e historial: qué versión es esta, y qué había antes.
- El control de cambios es gobierno: si un cambio propuesto está permitido, y quién tiene que aprobarlo.
- El control de cambios va primero: la clasificación y la aprobación son la puerta de entrada a una versión nueva, no al revés.
- Una edición menor y una edición mayor pueden llevar niveles distintos de control de cambios sin que cambie cómo funciona el control de versiones.
- La mayoría de procesos reales necesitan los dos, en capas: el control de cambios decide, el control de versiones recuerda.
Dos preguntas distintas, un objeto compartido
«¿Qué versión es esta?» y «¿debería producirse este cambio?» son dos preguntas distintas, y la mayoría de la documentación de procesos solo responde a la primera. El control de versiones es un mecanismo de etiquetado e historial: asigna un identificador a cada estado sucesivo de un documento, mantiene un registro de lo que había antes y te deja ver quién cambió qué y cuándo. Responde a preguntas de custodia después de los hechos. El control de cambios está aguas arriba de eso: es el proceso de gobierno que decide si un cambio propuesto está permitido, quién tiene que revisarlo y qué tiene que ser cierto antes de que se permita siquiera existir a una versión nueva.
El flujo de control de cambios de documentos de abajo hace visible el límite como diagrama en lugar de como frase. Las filas 1 a 8 son enteramente control de cambios: registrar la solicitud, clasificarla como menor o mayor, enrutar los cambios mayores a un revisor que evalúa el impacto completo, y hacerlo todo pasar por una decisión «¿Aprobado?». Nada de eso toca la versión del documento. Solo tras la puerta de aprobación se ejecuta «Actualizar el número de versión y la lista de distribución», en la fila 9: el punto exacto en el que empieza el control de versiones.
QueryChart mantiene las dos cosas separadas del mismo modo. Cada edición de un diagrama queda capturada automáticamente en un registro de cambios con diferencias por campo, una vista de comparar versiones y restauración en un clic: eso es control de versiones, funcionando lo pida alguien o no, en /features/version-control. Si una edición dada estaba permitida siquiera, y quién dio el visto bueno, es la pregunta de gobierno que responde un diagrama como el de abajo. Para la versión más completa y con más sabor de TI/operaciones de ese proceso de gobierno en lugar de la específica de documentos, ver /es/guides/como-crear-un-proceso-de-control-de-cambios.
Dónde termina el control de cambios y empieza el control de versiones
La clasificación, revisión y aprobación de un documento, y después la fila exacta donde cambia de verdad su número de versión.
Una solicitud, todavía no un cambio de versión
«Se identifica un cambio en un documento controlado» abre el diagrama, y después «Enviar solicitud de cambio de documento» y «Registrar la solicitud contra el expediente del documento»: tres filas de control de cambios, y la versión del documento sigue intacta.
Clasificación y aprobación lo condicionan todo
«¿Cambio clasificado como menor o mayor?» se divide en una edición por vía rápida o una revisión completa donde el revisor de cambios «evalúa el impacto completo» y lo registra contra documentos y formatos relacionados, antes de la decisión «¿Aprobado?»: nada de esto ha tocado todavía el número de versión.
La fila 9 es donde empieza el control de versiones
Solo una vez aprobado el cambio se ejecuta «Actualizar el número de versión y la lista de distribución», seguido de publicar en la ubicación controlada, notificar a los titulares de la lista de distribución y retirar la copia sustituida: la mitad de control de versiones del proceso.
Un rechazo vuelve al control de cambios
Una respuesta «Rechazado» envía la solicitud a «Revisar el borrador y volver a enviarlo a revisión», que vuelve a la evaluación de impacto del revisor de cambios: el retrabajo se queda íntegramente dentro del control de cambios hasta que «Documento reemitido bajo control de cambios formal» cierra el diagrama con una versión nueva en vigor.
Cómo funciona
Separa las dos preguntas en tu propio proceso
Antes de dibujar nada, decide qué pertenece al control de cambios (solicitud, clasificación, revisión, aprobación) y qué pertenece al control de versiones (identificador, número de revisión, historial, restaurar). Nombrar el límite es el paso de diseño que más diagramas de flujo se saltan.
Clasifica antes de evaluar
Enruta cada solicitud por una decisión menor/mayor antes de que empiece la evaluación, del modo en que lo hace la fila 4. Una corrección de redacción menor y un cambio de requisito mayor no deberían recorrer la misma vía de revisión, y decidir cuál es cuál de antemano evita que todo cambio reciba el tratamiento más pesado.
Pon el paso de control de versiones donde termina de verdad la aprobación
Incrementa el número de versión, fija la fecha de vigencia y actualiza la lista de distribución solo tras la puerta de aprobación, nunca antes. Si tu diagrama actualiza la versión antes de la decisión, has descrito un proceso que versiona borradores rechazados.
Dale al control de cambios su propio revisor, no al responsable del documento
Un revisor de cambios que evalúa el impacto completo y lo registra contra documentos y formatos relacionados, por separado de quien solicitó el cambio, es lo que hace que «aprobado» signifique algo. En el ejemplo, ese paso se sitúa entre la clasificación y la decisión de aprobación, sin fundirse con ninguna de las dos.
Deja que el control de versiones se ejecute solo una vez que el control de cambios ha decidido
Publicar, notificar a los titulares de la lista de distribución y retirar la copia sustituida son mecánicos una vez aprobado un cambio: esa es la cola de control de versiones del diagrama, y es la mitad que el registro de cambios y la vista de comparar versiones de QueryChart ya te resuelven en /features/version-control.
Errores que debes evitar
Tratar «tenemos historial de versiones» como control de cambios
Una herramienta que pone marca de tiempo a cada edición no es un proceso de gobierno: no tiene clasificación, ni revisor, ni puerta de aprobación. El historial de versiones responde qué cambió; no dice nada sobre si el cambio debería haber ocurrido.
Versionar un cambio antes de que esté aprobado
Si el número de versión se mueve antes de la decisión «¿Aprobado?», un borrador rechazado se sigue mostrando como una revisión nueva. Mantén el incremento en la fila 9, después de la aprobación, como hace el ejemplo.
Una única categoría para todo cambio
Pasar una corrección de errata por la misma revisión que un cambio de requisito o bien ralentiza las ediciones triviales o deja pasar las sustanciales por la vía rápida. La división menor/mayor de la fila 4 existe para que ambas reciban la cantidad correcta de escrutinio; ver /es/guides/como-crear-un-proceso-de-control-de-cambios para cómo diseñar las propias categorías.
Compara versiones en tu propio diagrama
Cada edición de este ejemplo ya se rastrea automáticamente: ábrelo y comprueba tú mismo el registro de cambios y la vista de comparar versiones.
Guías relacionadas
Preguntas frecuentes
¿Es el control de versiones lo mismo que el control de cambios?
No. El control de versiones es el mecanismo que identifica y recuerda los estados sucesivos de un documento (un número de revisión, un historial de quién cambió qué, y la capacidad de comparar o restaurar uno anterior). El control de cambios es el proceso de gobierno que decide si un cambio propuesto está permitido, quién lo revisa y qué tiene que ser cierto antes de aprobarlo. Un documento puede tener un control de versiones riguroso y ningún control de cambios en absoluto: cada edición guardada, sin que nadie decida si debía haberse hecho.
¿Cuál debería construir primero?
El control de versiones, porque suele estar ya funcionando por debajo: QueryChart mantiene un registro de cambios con diferencias por campo y una vista de comparar versiones para cada diagrama automáticamente, en /features/version-control. El control de cambios es la parte que hay que diseñar deliberadamente (categorías, un revisor, una puerta de aprobación), por lo que merece la pena dibujarla como diagrama de flujo, como el de esta página.
¿En qué se diferencia esto del control de revisiones?
En la práctica, «control de revisiones» y «control de versiones» son el mismo mecanismo con nombres distintos, ambos ocupados de identificar y rastrear los estados sucesivos de un documento. El control de cambios es el que difiere de verdad: gobierna si un cambio está permitido en primer lugar, y normalmente termina en una versión nueva una vez aprobado. Ver /es/guides/control-de-revisiones-frente-a-control-de-versiones si lo que intentas resolver es específicamente la cuestión del nombre control de revisiones/control de versiones.
¿Dónde encaja el control documental frente a estos dos?
El control documental es el más amplio de los tres: el ciclo de vida completo de un documento controlado, desde la solicitud pasando por el borrador, la revisión, la aprobación, la publicación y la eventual retirada o baja. El control de cambios y el control de versiones son ambos piezas suyas: el control de cambios gobierna una única edición propuesta, el control de versiones rastrea los identificadores y el historial que produce esa edición. Para el ciclo de vida completo en lugar de solo el límite entre cambio y versión, ver /es/templates/flujo-de-control-de-cambios-de-documentos o el más amplio /es/guides/como-crear-un-proceso-de-control-de-documentos.