확인 순서는 원문·선택 내용·저장 결과
이번 대상은 Git 병합에서 동일한 Markdown 본문에 경쟁 마커가 포함된 경우입니다. 저자가 만든 하나의 노트를 로컬 Git의 두 브랜치에서 편집하고, 실제 병합 실패, 원문 비교, 수동 수정을 확인했습니다. 여러 기기에서 동기화한 결과가 아닙니다.
- 양쪽 원문을 수동으로 남깁니다어떤 내용인지 구분할 수 있는 사본을 준비하십시오
- 차이를 비교합니다특이한 한 줄과 공통 부분을 확인합니다
- 채택할 내용을 결정합니다이 예는 양립할 수 있는 두 항목을 각각 다른 행으로 이동합니다
- 편집하고 저장합니다본문과 Git 측의 병합 완료를 확인합니다
- 다시 표시하고 확인합니다선택한 내용과 저장 Markdown을 대조합니다
이 순서는 이번 연습을 정리한 도표입니다. 자동 복원 및 소실 방지 보증, 동기화 서비스별 작업 절차를 보여주는 도표가 아닙니다.
우선, 자신의 경쟁 형태를 확인합니다
이 예에서는 Git 병합이 종료 코드 1에서 멈추고, 作業メモ.md이 UU가 되었습니다. Git의 인덱스에는 공통 원본 버전과 두 개의 편집 버전이 남아 있으며, 노트 본문에는 <<<<<<< HEAD, =======, >>>>>>> draft-b가 포함되어 있습니다.
귀하의 환경에서 별칭 충돌 파일이나 기록 화면이 표시되는 경우, 해당 동기화 방식에 맞추어 확인해 주시기 바랍니다. 방식을 조사하는 입구는 Obsidian의 동기화 방법 가이드입니다. 이 기사의 Git 결과를 Obsidian Sync이나 iCloud의 동작으로 바꿀 수 없습니다.
이번 경쟁 상태로 저장된 본문은 다음과 같습니다. 마커를 포함하여 실제 파일의 전체를 게시하고 있습니다.
# 作業メモ
ローカルの競合を確かめるために著者が作った練習用ノートです。
## 次の確認
<<<<<<< HEAD
- 確認する項目: 見出しの順番を確認する。
=======
- 確認する項目: 内部リンクの保存先を確認する。
>>>>>>> draft-b
1. 손에 있는 두 개의 원문을 각각 남겨두다
편집을 시작하기 전에, 손에 있는 각각의 버전을 원본 버전을 알 수 있는 이름으로 별도로 저장합니다. 하나만 가지고 있는 경우에는, 다른 쪽도 저장한 것으로 간주하지 말고, Git 상태와 사용 중인 방식의 기록을 확인하십시오. 각 서비스의 기록에서 복구하는 작업은 이번에 시도하지 않았습니다.
경합을 수정하기 전에 이전 본문으로 되돌릴 준비를 확인하려면, Git·File Recovery·보관함 외부 복사 복원 예시도 참고하십시오.
이 연습에서는, merge 전에 저자가 안 A·안 B의 사본을 수동으로 보관했습니다. 비교를 위해 보관함 안에도 原文の控え/案A.md과 原文の控え/案B.md을 놓고 열었습니다. 이것들은 동기화 도구가 자동으로 생성한 conflicted copy가 아닙니다.
| 버전 | 특이한 확인 항목 | 공통 부분 |
|---|---|---|
| 안 A | 제목 순서를 확인합니다 | 제목, 연습용 노트 설명, 다음 확인이라는 제목 |
| 안 B | 내부 링크의 저장 대상을 확인합니다 | 안 A와 동일 |
업데이트 시각만으로 판단하지 않고, 문장을 읽어 필요한 정보를 확인합니다. 이번 두 항목은 별도의 확인 항목으로 병행되므로, 저자는 A·B 순서대로 두 줄 모두 채택하기로 결정했습니다 실제 문장이 모순되거나 중복되는 경우에는 그 내용에 맞추어 선택해야 합니다.
2. 결정한 내용을 Obsidian에서 편집하고, 저장을 확인합니다
실제 Obsidian 편집기에서 作業メモ.md을 열고, 선택한 본문을 입력했습니다. 이 예에서는 공통 설명을 남기고, 두 항목을 별도의 행으로 만들며, 충돌 마커를 제거했습니다. 자동 저장을 기다리며, 실제 파일에 다음 전체가 저장되었는지 확인하고 있습니다.
# 作業メモ
ローカルの競合を確かめるために著者が作った練習用ノートです。
## 次の確認
- 確認する項目: 見出しの順番を確認する。
- 確認する項目: 内部リンクの保存先を確認する。
자신의 노트에서도 마커가 사라진 것에 더해, 선택한 내용, 행 순서, 남기기로 결정한 공통 부분을 다시 읽습니다. 본문을 정리하는 판단과 Git 측에서 머지를 완료하는 작업은 별도로 확인합니다.
3. Git의 미해결 상태를 확인하고, 병합을 완료합니다
이 연습에서는 Obsidian으로 본문을 저장한 후에도 Git의 상태는 UU이었습니다. 그 후, 대상 노트만 명시하고 git add를 적용한 뒤 로컬에서 merge 커밋을 만들었습니다. 두 개의 원본 커밋이 부모로 남아 있으며, git ls-files -u은 비어 있으며, Git의 상태는 clean이 되었습니다.
다음은 로컬 Git에서 대상 파일을 확인하는 명령 예시입니다. 실제 노트 이름과 리포지토리를 확인하여 사용합니다. git add 이전에 채택할 본문과 다른 작업 상태를 확인해 주세요.
git status --short -- "作業メモ.md"
git ls-files -u -- "作業メモ.md"
# 採用する本文を確認した後、対象ノートをstageする
git add -- "作業メモ.md"
git commit
# merge完了後の未解決indexと状態を確認する
git ls-files -u
git status --shortGit 작업은 로컬 명령으로 수행했습니다. Obsidian Git 플러그인은 사용하고 있지 않으며, remote, push/pull, 다른 기기에 반영되는 것을 확인하지 않았습니다. 상태가 clean인 것조차도 백업의 내구성이나 모든 단말기로의 배송을 증명하지 않습니다.
4. 노트를 다시 열고, 선택한 내용을 읽습니다
merge commit을 만든 후, 실제 파일 탐색기에서 作業メモ.md을 다시 열었습니다. 읽기 뷰에 두 개의 항목이 표시되고, 충돌 마커는 없었습니다. 재표시 전후의 Markdown은 동일한 SHA256이며, 원본 A·B의 사본과 각 커밋 본문도 유지되었습니다.
이 결과는 이 저자 작성 노트와 한 번의 로컬 복원으로 확인한 것입니다. 모든 경쟁 및 모든 동기화 방식에서 정보가 손실되지 않음을 나타내는 결과는 아닙니다.
원문·경합 상태·저장 결과를 다운로드하기
네 개의 Markdown은 원문 A/B, 경쟁 상태, 최종 저장 결과의 원본입니다. 배포명은 상태를 구분하기 위한 별명이며, 실제 작업 노트명은 作業メモ.md이었습니다. 내용을 비교하는 연습에서는 서로 다른 이름으로 저장하고, 자신의 노트에 있는 동일한 이름 파일을 덮어쓰지 않는 곳에서 확인해 주세요.
| 상태 | 배포 파일 |
|---|---|
| 원문 A | original-a.md |
| 원문 B | original-b.md |
| 경합 상태 | conflicted-note.md |
| 저장 결과 | resolved-note.md |
배포 파일의 독자 측에서의 가져오기·복원 작업은 이번 실앱 검증에 포함되지 않습니다.
자주 묻는 질문
본문의 경쟁 마커와 conflicted copy는 동일합니까?
두 문장을 모두 남기면 해결할 수 있습니까?
경쟁 마커를 삭제하고 저장하면 Git 병합도 완료됩니까?
이 절차는 Obsidian Sync 및 iCloud에서도 검증되었습니까?
검증 환경 및 확인 범위
- 실제 앱:2026년9월30일의 Linux 버전 Obsidian 1.13.7. 저자가 만든 일본어 노트, 하나의 오프라인 로컬 Git 리포지토리, 커뮤니티 플러그인 없음.
- 실제 Git 결과:merge 실패, UU, 미해결 인덱스의 3단계, 충돌 마커, 명시된 대상의 stage와 두 개의 부모를 가진 merge 커밋, 미해결 인덱스가 비어 있음, 상태 clean.
- 실 GUI：원문 A·경합 노트·저장 후 노트의 실제 파일 탐색기 작업, 실제 편집기에서 선택한 본문 입력 및 저장, 읽기 뷰, 노트 재표시 확인.
- 보조:합성 노트와 원문 사본을 파일로 직접 준비했습니다. 좌우 분할 및 B 표시, 사이드바, 설정 창, 상태 읽기에는 앱 API를 사용했습니다. Git은 로컬 셸 작업입니다.
- 미검증:자동conflicted-copy 생성, Obsidian Sync, iCloud, 기타 동기화 서비스, remote, 두 대에서 동시 편집, iOS/Android/Mac, SimpleMemo 배송, 장기 백업, 속도, 생산성, 유입 효과.
원본 이미지는 가공되지 않은 실제 Obsidian 화면이며, Markdown은 실제 파일의 원본입니다. 검증 기록과 원본 대응에 실제 조작·보조·한계를 기재하고 있습니다.
방식을 확인하는 입구
동기 방법 비교 가이드는 방식을 선택하기 위한 기존 기사입니다. 이 페이지는 원문을 비교하여 복원하는 사례로서 주제를 구분하고 있습니다. 이 기사에서는 SimpleMemo의 입력 및 배송을 시도하지 않았습니다.
본 사이트는 YURIKA, K.K.가 운영하며, 독립 앱 “SimpleMemo”을 소개하고 있습니다. Obsidian 공식에 의한 기사가 아닙니다.