我正在考虑向其用户提供对 SaaS 应用程序使用的资源的某种 Git 访问权限的想法。这将允许用户通过 Git 界面以及应用程序的本地基于 Web 的界面编辑和推送内容。我主要关心的是当用户编辑基于 Web 的界面中的内容时如何协调合并冲突（我不太关心来自 Git 界面的合并冲突，因为 Git 和他们的 Git 客户端应该处理这个问题）。这与 GitHub 允许基于 Git 和基于 Web 的访问其 Wiki 的方式非常相似，我很好奇他们如何处理这种情况，作为其他人在提供基于 Web 和基于 Git 的访问时遵循的模式内容。
如果用户通过 Web 界面编辑 GitHub 上的 Wiki 页面，而另一个用户在完成之前将更改推送到 Wiki 存储库分支，那么当他们保存更改时会发生什么？它是使用“最后一个获胜”还是“抱歉，在新版本上重做所有更改”？
我发现了一篇相关的 SO 帖子，它总体上讨论了这个问题，但我很好奇 GitHub 是如何专门处理它的，因为它得到了 Git 的支持，而 Git 已经内置了一些合并功能。
对 GitHub wiki 所做的每一项更改，无论是在 Web 界面中还是通过 git 完成，都是它自己在存储库中的提交。
如果您通过 Web 界面添加、编辑或删除 wiki 页面，然后git pull通过 wiki 存储库，您可以使用git history. 如果您是 wiki 所属项目的所有者或合作者，您甚至可以使用 git 还原该提交并将更改推送回 GitHub（我个人不得不这样做以恢复被意外删除的页面）。
对于您描述的情况，似乎（根据this issue）最后一次编辑获胜，而第一次编辑的内容丢失。
要获得比这更具体的答案，您可能需要查看Gollum项目，这是 GitHub 用来管理其 git 支持的 wiki 的项目。
我正在开发一个 git 支持的 wiki 引擎，类似于名为Waliki的 Gollum 。
特别是，它更聪明地合并更改：Waliki 不是硬性的“更新胜利”方法，而是在一个分离的分支中处理每个版本，并在保存时将它们合并。
如果一个页面在一个编辑过程中发生了外部变化并且 git 可以自动合并它，用户会收到通知。如果合并失败，页面仍会保存，但会重新加载编辑器，要求用户修复冲突。
我很高兴收到一些反馈。