4

私は、SaaSアプリケーションが使用するリソースへのある種のGitアクセスをそのユーザーに提供するというアイデアをいじっています。これにより、ユーザーはGitインターフェースおよびアプリケーションのネイティブWebベースのインターフェースを介してコンテンツを編集およびプッシュできます。私の主な関心事は、ユーザーがWebベースのインターフェイスでコンテンツを編集するときにマージの競合を調整する方法です（GitとそのGitクライアントがそれを処理する必要があるため、Gitインターフェイスからのマージの競合についてはそれほど心配していません）。これは、GitHubがGitベースとWebベースの両方のWikiへのアクセスを許可する方法と非常に似ています。WebベースとGitベースの両方のアクセスを提供するときに、他の人が従うパターンとしてこの状況をどのように処理するのか興味があります。コンテンツ。

ユーザーがWebインターフェイスを介してGitHubのWikiページを編集し、別のユーザーが終了する前にWikiリポジトリブランチに変更をプッシュした場合、変更を保存するとどうなりますか？「最後の1つが勝つ」または「申し訳ありませんが、新しいバージョンですべての変更をやり直す」を使用しますか？

問題全般について説明している関連するSO投稿を見つけましたが、GitHubが具体的にどのように処理するのか非常に興味があります。これは、すでにいくつかのマージ機能が組み込まれているGitに支えられているためです。

4

2 に答える 2

4

GitHub wikiに加えられたすべての変更は、Webインターフェイスで行われたか、Gitを介して行われたかに関係なく、リポジトリ内での独自のコミットです。

Webインターフェイスを介してWikiページを追加、編集、または削除してからgit pull、Wikiリポジトリを使用すると、で編集を確認できますgit history。あなたがwikiが属するプロジェクトの所有者または共同作業者である場合は、そのコミットを元に戻し、gitを使用して変更をGitHubにプッシュすることもできます（誤って削除されたページを復元するには、個人的にこれを行う必要がありました） ）。

あなたが説明する状況では、（この問題によると）最後の編集が優先され、最初の編集の内容が失われるように見えます。

それよりも具体的な答えについては、GitHubがgit-backedwikiを管理するために使用しているGollumプロジェクトをご覧ください。

于 2012-05-26T08:19:35.383 に答える
2

Walikiという名前のGollumに似たGitベースのウィキエンジンを開発しています。

特に、変更をマージするのは少し賢いです。難しい「新しい勝利」アプローチの代わりに、Walikiは分離されたブランチのすべてのエディションを処理し、保存時にそれらをマージします。

エディション中にページに外部の変更があり、gitがそれを自動的にマージできる場合、ユーザーに通知されます。マージが失敗した場合でも、ページは保存されますが、エディターが再ロードされ、ユーザーに競合を修正するように求められます。

フィードバックをいただければ幸いです。

于 2014-11-25T15:27:04.233 に答える