gitバージョン管理システムを使用してバイナリファイルをロックする
1年半の間、SVNからの切り替えを期待して、gitコミュニティに注目しています。私を妨げている特定の問題の1つは、バイナリファイルをロックできないことです。過去1年間、私はこの問題に関する進展をまだ見ていません。ファイルのロックは分散ソース管理の基本原則に反することを理解していますが、バイナリファイルの競合の可能性がある場合に、Web開発会社がgitを利用してソースコードと画像ファイルの変更を追跡する方法はわかりません。
ロックの効果を実現するには、「中央」リポジトリを識別する必要があります。 gitの分散性に関係なく、ほとんどの企業にはソフトウェアプロジェクトの「中央」リポジトリがあります。指定されたアドレスで管理しているgitリポジトリからのロックが必要であるとしてファイルをマークできるはずです。 gitはファイルではなくファイルの内容を追跡するため、おそらくこれは困難になりますか？
変更する前にロックする必要のあるgitおよびバイナリファイルを扱った経験がありますか？
注：Source Gearの新しいオープンソース分散バージョン管理プロジェクトであるVeracityには、その目標の1つとしてロック機能があるようです。
Git LFS 2. はファイルロックのサポートを追加しました。
Git LFS 2.0.0を使用すると、作業中のファイルをロックできるようになり、ファイルを再度ロック解除するまで、他のユーザーがGit LFSサーバーにプッシュできなくなります。
これにより、ファイルシステムレベルでのマージの競合や、マージ不可能なファイルでの作業の損失が防止されます。 Gitの分散および並列の性質と矛盾するように思えるかもしれませんが、ファイルロックは、特にバイナリアセットを扱う大規模なチームにとって、多くのソフトウェア開発ワークフローの重要な部分です。
Subversionにはロックがあり、単なる助言ではありません。これらはsvn:needs-lock属性を使用して強制できます（必要に応じて意図的に破壊することもできます）。マージ不可能なファイルを管理するための適切なソリューションです。私がSubversionのほぼすべての店で働いている会社で、マージできないすべてのファイルにsvn:needs-lockを使用しています。
「ロックは単なる通信方法です」には同意しません。電話や電子メールなどのプッシュ通知よりもはるかに効果的な方法です。 Subversionロックは自己文書化されています（ロックを持っている人）。一方、電子メールなどの他の従来のプッシュ通知チャネルで通信する必要がある場合、誰に通知を送信しますか？開発チーム全体の完全なリストがない限り、特にオープンソースプロジェクトで、誰がファイルを編集するかを事前に知ることはできません。したがって、これらの従来の通信方法は、それほど効果的ではありません。
中央ロックサーバーは、DVCSの原則に反しますが、マージ不可能なファイルに対して実行可能な唯一の方法です。 DVCSが中央ロック機能を持たない限り、Subversionを使用するために働いている会社を維持すると思います。
より良い解決策は、すべてのバイナリファイル形式用のマージツールを作成することですが、それは「完成」することのない長期的かつ継続的な目標です。
環境によっては、バイナリファイルのロックが必要な機能であることに同意します。ただし、これを実装する方法について考えただけです。
- （「svn：needs-lock」プロパティのように）「needs-lock」としてファイルをマークする方法があります。
- チェックアウト時に、gitはそのようなファイルを読み取り専用としてマークします。
- 新しいコマンド
git-lockは、どこかで実行されている中央ロックサーバーにアクセスして、ロックの許可を求めます。 - ロックサーバーがアクセス許可を付与する場合、ファイルに読み取り/書き込みのマークを付けます。
git-addは、ロックされたファイルのコンテンツハッシュをロックサーバーに通知します。- ロックサーバーは、そのコンテンツハッシュがマスターリポジトリのコミットに現れるのを監視します。
- ハッシュが表示されたら、ロックを解除します。
これは非常に中途半端なアイデアであり、あらゆる場所に潜在的な穴があります。また、gitの精神に反しますが、一部のコンテキストでは確かに有用です。
特定の組織内では、この種のことは、おそらくスクリプトラッパーとコミットフックの適切な組み合わせを使用して構築できます。
バイナリの複数の場所で発生する変更に関するマリオの追加の懸念に応えて。したがって、シナリオはアリスとボブの両方が同じバイナリリソースに同時に変更を加えていることです。それらはそれぞれ、1つの中央リモートからクローン化された独自のローカルリポジトリを持っています。
これは確かに潜在的な問題です。したがって、アリスは最初に終了し、中央のalice/updateブランチにプッシュします。通常、これが発生すると、アリスはレビューする必要があることを発表します。ボブはそれを見て、レビューします。 （1）それらの変更を自分のバージョンに組み込む（alice/updateから分岐して変更する）か、（2）自分の変更をbob/updateに公開することができます。再び、彼は発表を行います。
現在、アリスが代わりにmasterにプッシュする場合、ボブはmasterを引き出して自分のローカルブランチにマージしようとするとジレンマに陥ります。彼のアリスとの対立。ただし、繰り返しますが、同じ手順を異なる分岐にのみ適用できます。そして、たとえボブがすべての警告を無視してアリスにコミットしたとしても、アリスのコミットを引き出して問題を修正することは常に可能です。これは単に通信の問題になります。
（AFAIK）Subversionロックは単なる助言であるため、電子メールまたはインスタントメッセージでも同じ目的を果たすことができます。しかし、そうしなくても、Gitで修正できます。
いいえ、ロック機構自体はありません。ただし、ロックメカニズムは、良好な通信の代わりになるだけです。それが、Git開発者がロックメカニズムを追加していない理由だと思います。
最近、Git（以前はSubversionを使用）の使用を開始しましたが、ロックを必要とせずに、問題に役立つワークフローの変更を発見しました。 gitの設計方法とブランチの簡単さを利用しています。
基本的に、非マスターブランチにプッシュし、そのブランチのレビューを行ってから、マスターブランチ（またはターゲットブランチのいずれか）にマージします。
Gitの使用方法は「意図」されており、各開発者は独自のパブリックリポジトリを公開します。 Subversionユーザーはそれで問題を抱えていることがわかりました。そのため、代わりに、中央リポジトリのブランチツリーにプッシュします。各ユーザーは独自のブランチツリーを持ちます。たとえば、次のような階層が機能する場合があります。
users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey
独自の構造を自由に使用してください。また、別の一般的なgitイディオムであるトピックブランチも示しています。
次に、ユーザーaのローカルリポジトリで：
feature1
feature2
そして、それを中央サーバー（Origin）に取得するには：
git Push Origin feature1:users/a/feature1
（これはおそらく構成の変更により簡素化できます）
とにかく、feature1がレビューされると、責任者（この場合、それは機能の開発者であり、1人のユーザーがマスターへのマージを担当することができます）は、次のことを行います。
git checkout master
git pull
git merge users/name/feature1
git Push
プルはフェッチを実行し（新しいマスターの変更をプルしますおよび機能ブランチ）、マスターを中央リポジトリの内容に更新します。ユーザーaがジョブを実行し、マスターを適切に追跡した場合、マージに問題はありません。
これは、ユーザーまたはリモートチームがバイナリリソースに変更を加えた場合でも、マスターブランチに組み込まれる前にレビューされることを意味します。また、マスターブランチに何かがいつ入るのかについては、（プロセスに基づいて）明確な線引きがあります。
また、gitフックを使用してプログラムでこの側面を強制することもできますが、繰り返しますが、これらについてはまだ作業していないので、それらについて話すことはできません。
Subversionを使用していたとき、svn:needs-lockすべてのバイナリおよび編集が困難なテキストファイルのプロパティ。 I never実際に競合が発生しました。
さて、Gitでは、そのようなことは心配していません。覚えておいてください。Subversionのロックは実際には必須のロックではなく、単なるコミュニケーションツールです。そして、推測してみてください。通信にSubversionは必要ありません。電子メール、電話、IMでうまく管理できます。
別のことは、多くのバイナリ形式をプレーンテキスト形式に置き換えることです。 reStructuredTextまたはLaΤを使用しますΕWord Wordの代わりに、Excelの代わりにCSV、Visioの代わりにASCII-Art、データベースの代わりにYAML、OOの代わりにSVG、MIDIの代わりにabcなど）。
現在のワークフローを調べて、画像のロックが本当に必要かどうかを確認する価値があります。 2人で画像を個別に編集することは比較的まれであり、少しのコミュニケーションが大いに役立ちます。
この問題についてはgitディスカッショングループで議論しましたが、現時点ではnoがgitの集中ファイルロックの方法に同意していると結論付けました。
TortoiseGitは、Office自体にdiffを委任するOfficeドキュメントの完全なgitワークフローをサポートします。また、OpenDocument形式のOpenOfficeに委任します。
CADファイルはどうですか？ファイルがロックされておらず、読み取り専用に保たれている場合、ほとんどのcadプログラムは、任意のvcsによって新しいファイルとして認識される変更ビットを開くだけです。したがって、私の見解では、ロックは特定のファイルを変更する意図を伝えるための理想的な手段です。同様に、そもそも一部のソフトウェアが書き込みアクセスを取得することを防ぎます。これにより、ソフトウェアまたは少なくともすべてのファイルを完全に閉じる必要なく、ローカルファイルを更新できます。
ロックするファイルを含むテキストファイルをccに挿入し、更新フックに拒否させます。
プロジェクトを再編成するとロックの回避に役立つことは事実かもしれませんが、次のとおりです。
- チームは他の優先順位（場所、顧客など）によっても編成されます。
- ツールは他のターゲット（互換性、価格、ほとんどの従業員による使いやすさ）によっても選択されます
- 一部のツール（したがって、バイナリファイル）は、同じ仕事をすることができ、同じ価格で同じ会社のニーズに適合する代替物がないため、回避できません。
会社全体がワークフローを再編成し、バイナリを生成するすべてのツールを置き換えて、ロックが不足しているためにgitでしか動作できないように要求することは、非常に効率が悪いようです。
ロックはgitの哲学（バイナリ用に作成されたことはありません）には合いませんが、無視できない状況があり、ロックがこのような問題を解決する最も効率的な方法です。
ファイルロックがgitの機能として機能することを期待していません。主にどのようなバイナリファイルに興味がありますか？あなたは実際にファイルをロックすることに興味がありますか、それともそれらをマージすることができないことによって引き起こされる競合を防ぐことです。
誰かがgitでOpenOfficeドキュメントのマージのサポートを話している（または実装している）ことを覚えているようです。
これは解決策ではなく、ロックメカニズムが必要な理由に関するコメントです。一部の分野では、ミッションクリティカルなフラットなバイナリのみの形式を使用するツールがいくつかあり、「より優れた/異なるツールを使用する」という選択肢はありません。実行可能な代替ツールはありません。私が本当によく知っているものは、同じ情報をascii形式で保存しても、マージの候補にはなりません。私が聞いた反論の1つは、オフラインで作業できるようにしたいということです。私が考えている特定のツールは、ライセンスをプルする必要があるため、とにかくオフラインで動作しません。ラップトップにデータがある場合、とにかく電車の中でツールを実行することはできません。つまり、接続が遅い場合にgitが提供することは、ライセンスを取得し、変更をプルダウンすることもできますが、異なるバージョンを見るための高速なローカルコピーを持つことです。これは、この場合でもDVCSが提供する素晴らしいことです。
一つの見方は、gitは単に使用するツールではないが、それで管理されるすべてのテキストファイルにとって素晴らしいことであり、異なるファイルに対して異なるバージョン管理ツールを必要とすることは面倒です。
メール経由のアドバイスロックのアプローチは本当に悪臭を放ちます。私はそれを見て、「編集中です」、「編集が完了しました」という電子メールの無限の流れにうんざりしており、それによって変更が失われているのを見ました。私が考えている特定のケースは、小さなアスキーファイルのコレクションがはるかに優れていたはずのケースでしたが、それは別です。
私は同じ問題のために私の会社でgitを使用することを提案していません。すべての設計にEAを使用し、ドキュメントにMicrosoft Wordを使用しています。特定のファイルを編集できるユーザーが事前にわからないため、排他ロックが唯一のオプションです。
gitは、各開発者がコードまたはファイルに対して単独で責任を負う非チーム環境で非常にうまく機能します。その場合、ロックに関する通信は必要ないからです。
組織がチーム環境を必要とする場合（通常、開発者を仕事のセキュリティから切り離すために）、svnを使用します。gitはあなたのためではありません。 SVNは、ソース管理とロックに関する開発者間の通信の両方を提供します。
Gitはファイルをロックするコマンドを提供していませんが、gitフックを使用してその機能を実現する方法に資金を提供しています。ロック情報を保存するには、補助サーバーが必要です。コミット前のフックを使用して、コミットされたファイルのいずれかがロックされているかどうかを確認できます。また、誰かがファイルをロックした場合、プログラムは補助サーバーにロッカーとロックされたファイルの情報を伝える必要があります。