GitHubはリポジトリ経由でWebベースのWiki編集をどのようにマージするのですか？

Question

私はSaaSアプリケーションがユーザーに使っているリソースに何らかのGitアクセスを提供するという考えを持っています。これにより、ユーザは、GitインタフェースやアプリケーションのネイティブWebベースインタフェースを通じてコン​​テンツを編集したりプッシュしたりすることができます。私の主な関心事は、ユーザーがWebベースのインターフェースのコンテンツを編集しているときにマージの競合を調整する方法です（GitとGitクライアントがそれを処理する必要があるため、Gitインターフェイスとのマージの競合はあまり気にしません）。これは、GitHubがGitベースのアクセスとWebベースのアクセスの両方をWikiに許可する方法と非常によく似ていますが、WebベースとGitベースの両方のアクセスを提供する際に、コンテンツ。

ユーザーがWebインターフェイスからGitHubのWikiページを編集し、別のユーザーが変更を保存する前にWikiリポジトリブランチに変更をプッシュすると、変更が保存されるとどうなりますか？ 「最後のものが勝つ」か、「新しいバージョンですべての変更をやり直してください」を使用していますか？

は、私は一般的に、問題を議論し related SO postを見つけましたが、私はそれがすでに焼かいくつかのマージ機能を持つGitリポジトリに裏打ちされていますので、GitHubには、具体的にそれをどのように処理するか非常に興味があります。

Answer 1

のGitHubに行われたすべての変更をwikiは、Webインターフェイスで行っても、gitで行っても、リポジトリ内での独自のコミットです。

Webインターフェイスからwikiページを追加、編集、または削除した後、git pull wikiリポジトリを編集すると、git historyの編集が表示されます。もしあなたがウィキが所有するプロジェクトのオーナーまたは協力者であれば、そのコミットを元に戻してgitを使って変更をGitHubにプッシュすることもできます（私は個人的にこれをやって、誤って削除されたページを回復しなければなりませんでした）。

あなたが記述した状況では、最後の編集が勝ち、最初の編集の内容が失われて表示されます（this issueによる）。

もっと具体的な答えは、Gollumプロジェクトを参照してください。このプロジェクトは、git-backed wikiを管理するためにGitHubが使用するプロジェクトです。

Answer 2

私はWalikiというGollumに似た、gitに裏打ちされたwikiエンジンを開発しています。

特に、よりスマートな変更をマージしています。新しい「勝利」アプローチの代わりに、Walikiはすべてのエディションを分離支店で処理し、をに保存します。

編集中にページに外部的な変更があり、gitが自動的にマージできる場合、ユーザーに通知されます。マージに失敗した場合でも、ページは保存されますが、コンフリクトを修正するようにエディタが再ロードされます。

フィードバックを受け取ってうれしく思います。