01
Compara el avance rápido
Si main es ancestro de feature, merge mueve main al nodo existente. Solo el caso divergente añade un commit con dos padres.
Git & Version Control
simulador GitMira el historial antes del comando
Elige un caso y previsualiza el cambio de historial sin ejecutar Git.
simulador Git
Grafo de commits de ejemplo
A–D y las primas son identificadores didácticos, no hashes Git.
Vista previa del historial
Elige un ejemplo y una operación para ver aquí el resultado.
Solo se procesa el grafo didáctico fijo en este navegador; no se lee ni contacta ningún repositorio.
Opciones
Rama destino: main · Rama origen: feature
Ctrl/Cmd + Enter previsualiza la operación elegida.
Elige una operación para ver su resultado.
El grafo modela archivos fijos de una línea, no la estrategia de merge de tu repositorio.
Un simulador Git ayuda a entender qué puntero cambia cuando main y feature se separan de un ancestro común. El grafo de commits del ejemplo permite comparar las tres operaciones sin pegar datos de un repositorio real.
Cambia al caso de avance rápido o al conflicto donde ambos lados modifican la misma línea. A, B, C y D son nombres didácticos, no hashes reales ni garantías sobre tu rama de trabajo.
¿Por qué usar este simulador Git?
Tres operaciones, una misma historia inicial
El simulador Git conserva los nodos originales después de merge y dibuja copias nuevas después de rebase o cherry-pick. Como simulador de ramas Git, muestra también si se mueve main o feature.
Un conflicto que puede explicarse
El caso preparado compara la línea base de app.js con dos ediciones distintas. Así se entiende el conflicto de merge del ejemplo sin fingir que el grafo pueda inspeccionar los archivos de tu proyecto.
Tres pistas para interpretar el grafo
02
Sigue los commits copiados
Rebase vuelve a aplicar C y D como C′ y D′ y mueve feature. Cherry-pick copia solo el C o D elegido a main y mantiene la fuente intacta.
03
Actualiza antes de copiar
Al cambiar el caso o la operación, el resultado anterior caduca y no se puede copiar ni descargar. Ctrl/Cmd + Enter crea una vista nueva; sustituye los nombres y el hash de ejemplo antes de usar el borrador.
Qué cambia en las tres operaciones
Merge no siempre crea un commit
Una unión divergente agrega un nodo con dos padres; el avance rápido mueve el puntero sin crear otro. Esto separa visualmente merge de la idea de “siempre hay commit de unión”.
Rebase frente a merge
Rebase reconstruye la secuencia feature sobre main y por ello muestra nodos con prima. Cherry-pick selecciona uno solo; ninguna prima representa un SHA de Git verdadero.
Conflicto limitado al archivo fijo
El modelo marca el punto donde el cambio de una línea del ejemplo no encaja. No simula la fusión textual completa ni calcula probabilidades de conflicto para tus archivos.
Límites del ejemplo
- No abre ni ejecuta repositorios
- El simulador Git no lee git log, rutas locales o URL remotas. Tampoco corre comandos ni conoce los cambios sin confirmar, permisos o políticas de servidor.
- No decide si es seguro publicar
- Los nombres main y feature son ejemplos. Antes de reescribir historia compartida, consulta la rama real, el estado del árbol de trabajo y el acuerdo del equipo.
- Solo una línea conocida para conflictos
- El caso app.js compara la base y las dos versiones preparadas. Git real puede resolver texto o renombres de otra manera; aquí no se editan conflictos ni se ejecuta --continue.
- Sin consola Git arbitraria
- No se admiten push, pull, stash, squash, revert, comandos libres ni rebase interactivo. Un grafo fijo no contiene el estado suficiente para representar esas tareas.
Preguntas sobre el simulador Git
¿Cuál es la diferencia entre git rebase y git merge?
Merge conserva los commits originales de las dos ramas y puede crear un commit con dos padres; rebase reaplica los commits feature sobre una base nueva. El simulador Git enseña ambas formas sin escoger la política del equipo.
¿Cómo funciona git pull con la opción --rebase?
Tras obtener cambios remotos, esa opción reaplica los commits locales sobre la rama actualizada en vez de crear la unión habitual. Esta página muestra solo el rebase de ramas ya incluidas en el ejemplo; no conecta con remotos ni simula pull.
¿Para qué sirve rebase en Git?
Puede poner commits propios no compartidos sobre una base más reciente y dejar una historia lineal. Como crea nuevos objetos, hay que tener cuidado con ramas ya publicadas. Aquí solo se muestra la topología.
¿Por qué tengo un conflicto al hacer merge de una rama?
Si ambos lados modifican contenido incompatible desde la base común, Git puede detenerse. El ejemplo de app.js enseña dos valores distintos de una misma línea; no diagnostica la causa concreta de tu repositorio.
¿Cuál es la mejor manera de mantener un historial de Git limpio?
Depende del modo de colaboración: merge preserva la bifurcación y rebase reorganiza commits propios. Compara los grafos y acuerda la estrategia con el equipo; el borrador no comprueba si una rama compartida puede reescribirse.
¿El resultado difiere de la documentación de tu dispositivo?
Probar el simulador Git
Compara las tres operaciones en un mismo grafo, revisa el conflicto fijo y después verifica cada referencia antes de llevar el borrador a tu repositorio.