Obsidian / Ejemplo de recuperación de conflictos de Git
Conserva los originales y elige el contenidoResuelve los conflictos de Git en Obsidian
Conserva, compara y guarda los originales
Esta página es una traducción automática del original en japonés. Leer el original en japonés
Si aparecen marcadores de conflicto en una nota, conserva por separado las dos versiones originales y decide qué contenido mantener. En este pequeño ejercicio elegimos dos elementos, los guardamos en Obsidian y comprobamos que la fusión local de Git terminara y que la nota volviera a mostrarse correctamente.
El orden de confirmación es el texto original, el contenido seleccionado y los resultados de guardado
El objetivo esta vez es cuando se incluye un marcador de la competencia en el mismo texto Markdown en la fusión de Git. Edité una de las notas creadas por el autor con dos ramas del Git local, y confirmé el fallo de fusión real, la comparación del texto original y la corrección manual. No es el resultado de la sincronización con múltiples terminales.
- Deje manualmente ambos textos originalesPrepare una copia que pueda distinguir cuál es el contenido
- Compare la diferenciaCompruebe la línea inusual y las partes comunes
- Decida el contenido a adoptarEste ejemplo coloca dos elementos compatibles en líneas separadas
- Editar y guardarCompruebe la finalización de la fusión en el texto y el lado de Git
- Volver a mostrar y confirmarEncolar el contenido seleccionado y guardar Markdown
Este orden es un diagrama que organiza este ejercicio. No es un diagrama que muestre la garantía de restauración automática y prevención de pérdidas, y el procedimiento de operación para cada servicio de sincronización.
Primero, compruebe la forma de su competencia
En este ejemplo, Git merge se detuvo con el código de salida 1 y 作業メモ.md quedó marcado como UU. El índice de Git conservó la base común y ambas versiones editadas. En el texto aparecieron los marcadores <<<<<<< HEAD, ======= y >>>>>>> draft-b.
Si hay una pantalla de archivos de conflicto de alias o historial en su entorno, verifique de acuerdo con el método de sincronización. La entrada para comprobar el método es la guía de métodos de sincronización de Obsidian. Los resultados de Git en este artículo no se pueden leer en el comportamiento de Obsidian Sync o iCloud.
El texto guardado en este estado competitivo es el siguiente. Se publica el texto completo del archivo real, incluido el marcador.
# 作業メモ
ローカルの競合を確かめるために著者が作った練習用ノートです。
## 次の確認
<<<<<<< HEAD
- 確認する項目: 見出しの順番を確認する。
=======
- 確認する項目: 内部リンクの保存先を確認する。
>>>>>>> draft-b
1. Deje los dos textos originales a mano por separado
Antes de comenzar a editar, guarde cada versión a mano por separado con un nombre que muestre la versión original. Si solo tiene uno de ellos a mano, no trate al otro como si pudiera guardarlo, y compruebe el estado de Git y el historial del método que está utilizando. Esta vez no he intentado recuperar el historial de cada servicio.
Si desea comprobar la preparación para volver al texto anterior antes de solucionar el conflicto, consulte también Git, recuperación de archivos y recuperación de copias fuera de la tienda.
En este ejercicio, el autor conservó manualmente copias de las versiones A y B antes de la fusión. Para compararlas, también colocó y abrió 原文の控え/案A.md y 原文の控え/案B.md dentro de la bóveda. No son copias en conflicto generadas automáticamente por una herramienta de sincronización.
| versión | Cambió el elemento de confirmación | Parte común |
|---|---|---|
| Plan A | Compruebe el orden de los encabezados | Título, explicación de las notas de práctica, encabezado para la siguiente confirmación |
| Borrador B | Compruebe dónde guardar el enlace interno | Igual que el Plan A |
En lugar de juzgar solo por el tiempo de actualización, lea el texto y verifique la información necesaria. Dado que los dos son compatibles como elementos de confirmación separados esta vez, el autor decidió adoptar ambas líneas en el orden de A y B. Si la oración real es contradictoria o duplicada, debe elegir según el contenido.
2. Edita el contenido acordado en Obsidian y comprueba que se haya guardado
Abrimos 作業メモ.md en el editor real de Obsidian e introdujimos el texto elegido. En este ejemplo mantuvimos la explicación común, colocamos los dos elementos en líneas separadas y eliminamos los marcadores de conflicto. Esperamos al guardado automático y verificamos que el archivo real contuviera todo el texto siguiente.
# 作業メモ
ローカルの競合を確かめるために著者が作った練習用ノートです。
## 次の確認
- 確認する項目: 見出しの順番を確認する。
- 確認する項目: 内部リンクの保存先を確認する。
Además de la desaparición del marcador, releeré el contenido seleccionado, el orden de las líneas y las partes comunes que decidí dejar en mi cuaderno. La decisión de resumir el texto y la operación para completar la fusión en el lado de Git se confirmará por separado.
3. Compruebe el estado no resuelto de Git y complete la fusión
En este ejercicio, incluso después de guardar el texto con Obsidian, el estado de Git era UU. Después de eso, hice explícitamente git add con solo la nota de destino e hice una confirmación de fusión localmente. Las dos confirmaciones originales permanecen como padres, el git ls-files -u está vacío y el estado de Git está limpio.
El siguiente es un ejemplo del comando para comprobar el archivo de destino en el Git local. Compruebe el nombre real de la nota y el repositorio antes de usarlo. Antes de git add, compruebe el texto a adoptar y el otro estado de trabajo.
git status --short -- "作業メモ.md"
git ls-files -u -- "作業メモ.md"
# 採用する本文を確認した後、対象ノートをstageする
git add -- "作業メモ.md"
git commit
# merge完了後の未解決indexと状態を確認する
git ls-files -u
git status --shortLa operación Git se realizó con un comando local. El plug-in Obsidian Git no se utiliza, y el control remoto, el empuje/pull y la reflexión en otros terminales no han sido confirmados. El hecho de que la condición esté limpia no prueba la durabilidad de la copia de seguridad o la entrega a todas las terminales.
4. Vuelve a abrir el cuaderno y lee el contenido seleccionado
Tras crear el commit de merge, volvimos a abrir 作業メモ.md desde el explorador real de archivos. La vista de lectura mostró ambos elementos sin marcadores de conflicto. El archivo Markdown conservó el mismo SHA256 antes y después de abrirlo, y se mantuvieron las copias originales A y B y el contenido de cada commit.
Este resultado fue confirmado con la nota de este autor y una restauración local. No es un resultado que muestre que la información no se perderá en todos los conflictos y en todos los métodos de sincronización.
Descarga los originales, el estado en conflicto y el resultado guardado
Los cuatro archivos Markdown son los originales de las versiones A y B, el estado en conflicto y el resultado final guardado. Los nombres de descarga distinguen cada estado; la nota de trabajo se llamaba 作業メモ.md. Para practicar la comparación, guarda cada archivo con un nombre diferente en un lugar donde no sobrescriba tus notas del mismo nombre.
| Estado | File de distribución |
|---|---|
| Original A | original-a.md |
| Texto original B | original-b.md |
| Estado de la competencia | conflicted-note.md |
| Guardar resultados | resolved-note.md |
La operación de captura y recuperación en el lado del lector del archivo distribuido no está incluida en esta verificación real de la aplicación.
Preguntas frecuentes
¿Los marcadores de conflicto en el texto y la copia conflictiva son los mismos?
¿Puedo resolverlo si dejo ambas oraciones?
Si borro y guardo el marcador de conflicto, ¿se completará la fusión de Git?
¿Se ha verificado este procedimiento en Obsidian Sync y iCloud?
Entorno de verificación y rango de confirmación
- Aplicación real: 30 de septiembre de 2026 Linux versión Obsidian 1.13.7. Notas japonesas creadas por el autor, un repositorio Git local fuera de línea, sin complemento de la comunidad.
- Resultados reales de Git: fallo de fusión, tres niveles de UU, índice no resuelto, marcadores de conflicto, confirmación de fusión con etapa objetivo explícita y dos padres, el índice no resuelto está vacío, estado limpio.
- GUI real: Compruebe la operación del explorador de archivos real del texto original A, las notas de la competencia y las notas guardadas, introduzca y guarde el texto seleccionado en el editor real, lea la vista y vuelva a mostrar las notas.
- Auxiliario: La nota compuesta y la copia del texto original se prepararon directamente como archivos. Usé la aplicación API para dividir izquierda y derecha, mostrar B, barra lateral, ventana de configuración y leer el estado. Git es una operación de shell local.
- No verificado: Generación automática de copia en conflicto, Obsidian Sync, iCloud, otros servicios de sincronización, remoto, edición simultánea en dos dispositivos, iOS/Android/Mac, entrega SimpleMemo, copia de seguridad a largo plazo, velocidad, productividad, efecto de entrada.
La imagen original es la pantalla del Obsidian real que no se ha procesado, y el Markdown es el original del archivo real. El registro de verificación y la correspondencia original describen la operación real, la asistencia y los límites.
Entrada para comprobar el método
La guía de comparación de métodos de sincronización es un artículo existente para elegir un método. Esta página divide el tema como ejemplo de comparación y restauración del texto original. En este artículo, no he probado la entrada y entrega de SimpleMemo.
Este sitio es operado por YURIKA, K.K. e introduce la aplicación independiente "SimpleMemo". Este no es un artículo oficial de Obsidian.