确认的顺序是原文、选择内容、保存结果
这次的对象是，在Git的merge中相同的Markdown正文中加入竞争标记的情况。 用本地Git的两个分支编辑了作者制作的一个笔记，确认了实际的merge失败、原文的比较、手动修正。 不是在多个终端上同步的结果。
- 手动保留两份原文准备能够区分两边内容的副本
- 比较差异确认不同的一行和共同部分
- 决定采用的内容这个例子将兼容的两个项目分成不同的行
- 编辑并保存确认正文和Git侧的merge完成
- 重新显示并确认核对所选内容和保存Markdown
这个顺序是整理这次演习的图。 不是显示自动恢复和防止消失的保证、同步服务的每个操作步骤的图。
首先，确认自己的竞争形式
在这个例子中，Git的merge在结束代码1停止，作業メモ.md变成了UU。 Git的index有共同的原版和两个编辑版，笔记本正文有<<<<<<< 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方面完成merge的操作是分开确认的。
3。 确认Git的未解决状态，完成merge
在这个练习中，用Obsidian保存正文后，Git的状态也是UU。 之后，只明确说明目标笔记git add，在本地制作了merge commit。 两个原来的commit作为父存在，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 副本以及各次 commit 的正文也都保留了。
这个结果是通过这个作者制作的笔记和一次本地恢复确认的。 并不是所有冲突、所有同步方式都不会丢失信息的结果。
下载原文、竞争状态、保存结果
四个Markdown是原文A/B、竞争状态、最终保存结果的原件。 分发名是区分状态的别名，实际的工作笔记名是作業メモ.md。 在比较内容的练习中，请以不同的名字保存，在不覆盖自己笔记本的同名文件的地方进行确认。
| 状态 | 分发文件 |
|---|---|
| 原文A | original-a.md |
| 原文B | original-b.md |
| 竞争状态 | conflicted-note.md |
| 保存结果 | resolved-note.md |
分发文件的读者端的导入、恢复操作，不包括在这次的实际应用程序验证中。
常见问题
本文的冲突标记和conflicted copy是一样的吗？
两个句子都留下就能解决吗？
删除并保存冲突标记后，Git的merge也会完成吗？
这个步骤在Obsidian Sync和iCloud上也验证过了吗？
验证环境和确认范围
- 实际应用程序：2026年9月30日的Linux版Obsidian 1.13.7。 作者制作的日语笔记，一个离线本地Git存储库，没有社区插件。
- 实际的Git结果：merge失败，UU，未解决index的三个阶段，冲突标记，明确对象的stage和拥有两个父的merge commit，未解决index为空，状态clean。
- 实GUI：确认原文A、冲突笔记、保存后笔记的实文件浏览器操作、实编辑器中选择的正文的输入和保存、读取视图、笔记的重新显示。
- 辅助说明：合并后的笔记和原文副本是直接作为文件准备的。左右分屏、显示 B、侧边栏、设置窗口以及状态读取使用了应用 API。Git 操作在本地 shell 中完成。
- 未验证：自动conflicted-copy生成、Obsidian Sync、iCloud、其他同步服务、remote、两台同时编辑、iOS/Android/Mac、SimpleMemo配送、长期备份、速度、生产力、流入效果。
原始图像是未经加工的实际Obsidian的画面，Markdown是实际文件的原件。 验证记录和原件的对应中记载了实际操作、辅助、极限。
确认方式的入口
同步方法的比较指南是为了选择方式的现有报道。 这个页面作为比较原文复原的例子，将主题分开。 在这篇报道中没有尝试SimpleMemo的输入和配送。
本网站由YURIKA, K.K.运营，介绍独立应用程序“SimpleMemo”。 不是Obsidian官方的报道。