76

SVN からの切り替えを期待して、1 年半の間、私は git コミュニティに注目してきました。私を妨げている特定の問題の 1 つは、バイナリ ファイルをロックできないことです。過去 1 年間、この問題に関する進展はまだ見られませんでした。ファイルのロックが分散ソース管理の基本原則に反することは理解していますが、バイナリ ファイルの競合の可能性がある場合に、Web 開発会社が git を利用してソース コードとイメージ ファイルの変更を追跡する方法がわかりません。

ロックの効果を得るには、「中央」リポジトリを特定する必要があります。git の分散性に関係なく、ほとんどの企業はソフトウェア プロジェクト用の「中央」リポジトリを持っています。指定されたアドレスで管理 git リポジトリからのロックが必要であることをファイルにマークできるはずです。おそらく、git はファイルではなくファイルの内容を追跡するため、これは難しくなっていますか?

変更する前にロックする必要がある git およびバイナリ ファイルを扱った経験のある人はいますか?

注: Source Gear の新しいオープン ソース分散バージョン管理プロジェクトである Veracity は、ロックを目標の 1 つとしているようです。

4

17 に答える 17

74

Subversion にはロックがあり、それらは単なる助言ではありません。それらは属性を使用して強制できsvn:needs-lockます (ただし、必要に応じて意図的に壊すこともできます)。これは、マージ不可能なファイルを管理するための適切なソリューションです。私が働いている会社は、ほぼすべてを Subversion に保存しsvn:needs-lock、すべてのマージ不可能なファイルに使用しています。

「ロックは単なる通信手段」には同意しません。電話やメールなどのプッシュ通知よりもはるかに効果的な方法です。Subversion ロックは自己文書化されています (誰がロックを持っているか)。一方、電子メールなどの他の従来のプッシュ通知チャネルで通信する必要がある場合、誰に通知を送信しますか? 特にオープンソース プロジェクトでは、開発チーム全体の完全なリストがない限り、誰がファイルを編集するかを事前に知ることはできません。そのため、これらの従来のコミュニケーション方法はそれほど効果的ではありません。

中央ロック サーバーは、DVCS の原則に反しますが、マージ不可能なファイルに対して実行可能な唯一の方法です。DVCS に中央ロック機能がない限り、私が勤務する会社は Subversion を使用し続けることができると思います。

より良い解決策は、すべてのバイナリ ファイル形式のマージ ツールを作成することですが、これは長期的かつ継続的な目標であり、決して「完成」することはありません。

このトピックに関する興味深い読み物を次に示します。

于 2009-06-13T11:59:12.480 に答える
10

一部の環境では、バイナリ ファイルのロックが必要な機能であることに同意します。ただし、これを実装する方法について考えていました。

  • ファイルを「needs-lock」としてマークする方法があります (「svn:needs-lock」プロパティのように)。
  • チェックアウト時に、git はそのようなファイルを読み取り専用としてマークします。
  • 新しいコマンドgit-lockは、どこかで実行されている中央ロック サーバーに接続して、ロックの許可を求めます。
  • ロック サーバーが許可を与える場合は、ファイルに読み取り/書き込みのマークを付けます。
  • git-addロックされたファイルのコンテンツハッシュをロックサーバーに通知します。
  • ロック サーバーは、そのコンテンツ ハッシュがマスター リポジトリのコミットに表示されるのを監視します。
  • ハッシュが表示されたら、ロックを解除します。

これは非常に中途半端なアイデアであり、潜在的な穴がどこにでもあります。これは git の精神にも反しますが、状況によっては確かに便利です。

特定の組織内では、スクリプト ラッパーとコミット フックの適切な組み合わせを使用して、この種のものを構築することができます。

于 2008-09-23T07:26:20.927 に答える
10

バイナリの複数の場所で変更が発生しているというマリオの追加の懸念に応えて。したがって、アリスとボブの両方が同じバイナリ リソースに同時に変更を加えているというシナリオです。それぞれが、1 つの中央リモートから複製された独自のローカル リポジトリを持っています。

これは確かに潜在的な問題です。そのため、Alice が最初に終了し、中央alice/updateブランチにプッシュします。通常、これが発生すると、アリスはレビューする必要があることを発表します。Bob はそれを見てレビューします。彼は、(1) これらの変更を自分のバージョンに組み込む (そこから分岐しalice/updateて変更を加える) か、(2) 自分の変更を に公開することができbob/updateます。再び、彼は発表を行います。

代わりにAlice がプッシュすると、Bob はプルして自分のローカル ブランチにマージしようとするmasterときにジレンマに陥ります。master彼とアリスの対立。ただし、同じ手順を別のブランチに適用することもできます。また、ボブがすべての警告を無視してアリスのコミットをコミットしたとしても、アリスのコミットを引き出して問題を修正することは常に可能です。これは単にコミュニケーションの問題になります。

(私の知る限り) Subversion のロックは単なる助言であるため、電子メールやインスタント メッセージでも同じ目的を果たすことができます。しかし、そうしなくても、Git では修正できます。

いいえ、ロック機構自体はありません。しかし、ロック機構は、良好なコミュニケーションの代わりになる傾向があります。それが、Git 開発者がロック メカニズムを追加していない理由だと思います。

于 2008-09-26T17:49:50.423 に答える
8

最近 Git の使用を開始しました (以前は Subversion を使用していました)。ロックを必要とせずに、問題を解決できるワークフローの変更を見つけました。git の設計方法とブランチの容易さを利用しています。

基本的には、非マスター ブランチにプッシュし、そのブランチのレビューを行ってから、マスター ブランチ (またはターゲット ブランチが何であれ) にマージすることになります。

git が「意図的に」使用される方法として、各開発者は独自のパブリック リポジトリを公開し、他の開発者にそこからプルするように要求します。Subversion ユーザーはそれで問題を抱えていることがわかりました。そのため、代わりに、各ユーザーが独自のブランチ ツリーを持つ中央リポジトリのブランチ ツリーにプッシュします。たとえば、次のような階層が機能する場合があります。

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

独自の構造を自由に使用してください。また、git のもう 1 つの一般的なイディオムであるトピック ブランチも示していることに注意してください。

次に、ユーザー a のローカル リポジトリで:

feature1
feature2

そして、それを中央サーバー (オリジン) に取得するには:

git push origin feature1:users/a/feature1

(これはおそらく構成の変更で単純化できます)

いずれにせよ、feature1 がレビューされたら、責任者 (この場合、それは機能の開発者です。master へのマージを担当する単一のユーザーを持つことができます) は、次のことを行います。

git checkout master
git pull
git merge users/name/feature1
git push

プルはフェッチ (新しいマスターの変更と機能ブランチをプル) を行い、マスターを中央リポジトリにあるものに更新します。ユーザー a がジョブを実行し、マスターを適切に追跡した場合、マージに問題はないはずです。

これはすべて、ユーザーまたはリモート チームがバイナリ リソースに変更を加えた場合でも、マスター ブランチに組み込まれる前にレビューを受けることを意味します。そして、いつ何かが master ブランチに入るかについて (プロセスに基づく) 明確な線引きがあります。

git フックを使用してプログラムでこの側面を強制することもできますが、繰り返しますが、私はまだこれらを扱っていないので、それらについて話すことはできません。

于 2008-09-24T06:22:07.920 に答える
5

現在のワークフローを調べて、画像のロックが本当に必要かどうかを確認することは価値があります。2人で画像を個別に編集することは比較的まれであり、少しのコミュニケーションが大いに役立つ可能性があります。

于 2008-09-23T07:05:37.747 に答える
5

私はこの問題をgitディスカッショングループで議論しましたが、現時点では、gitの集中ファイルロックの方法について合意されていないと結論付けました。

于 2008-09-26T17:19:00.747 に答える
5

私が Subversion を使用していたときは、svn:needs-lockすべてのバイナリ ファイルや編集しにくいテキスト ファイルに対してもプロパティを設定していました。私は実際に紛争を経験したことはありません。

今、Git では、そのようなことを心配する必要はありません。覚えておいてください: Subversion のロックは実際には必須のロックではなく、単なるコミュニケーション ツールです。推測ですが、通信に Subversion は必要ありません。電子メール、電話、IM で問題なく管理できます。

私が行ったもう 1 つのことは、多くのバイナリ形式をプレーン テキスト形式に置き換えることです。Word の代わりにreStructuredText または LaΤ Ε Χ、Excel の代わりに CSV、Visio の代わりに ASCII-Art、データベースの代わりに YAML、OO Draw の代わりに SVG、MIDI の代わりに abc などを使用します。

于 2008-09-23T20:59:52.407 に答える
2

ファイルロックがgitの機能として機能することは期待していません。主にどのような種類のバイナリファイルに関心がありますか？実際にファイルをロックすることに興味がありますか、それとも単にファイルをマージできないことによって引き起こされる競合を防ぐことに興味がありますか。

誰かがOpenOfficeドキュメントをgitにマージするためのサポートについて話している（または実装している）ことを覚えているようです。

于 2008-09-23T07:00:30.223 に答える
1

TortoiseGit supports full git workflow for Office documents delegating diff to Office itself. It works also delegating to OpenOffice for OpenDocument formats.

于 2011-02-13T10:24:49.503 に答える
1

cadファイルはどうですか？ファイルがロックされておらず、読み取り専用に保たれている場合、ほとんどの CAD プログラムはファイルを開いて任意のビットを変更し、VC からは新しいファイルとして認識されます。したがって、私の見解では、ロックは、一部のファイルを変更する意図を伝えるための理想的な手段です。また、一部のソフトウェアが最初に書き込みアクセスを取得するのを防ぎます。これにより、ソフトウェアまたは少なくともすべてのファイルを完全に閉じる必要なく、ローカル ファイルを更新できます。

于 2009-09-01T15:58:05.473 に答える
0

ロックするファイルを含むテキストファイルをccに入れて、更新フックで拒否するだけです。

于 2010-12-04T05:44:10.090 に答える
0

git は、各開発者がコードやファイルの一部を単独で担当する非チーム環境で非常にうまく機能します。その場合、ロックに関する通信は必要ないからです。

あなたの組織がチーム環境を必要とする場合 (通常、開発者を職の安全から解放するため)、svn を使用してください。git は適していません。Svn は、ソース管理とロックに関する開発者間の通信の両方を提供します。

于 2010-01-06T18:02:42.790 に答える
0

プロジェクトを再編成するとロックを回避できるというのは本当かもしれませんが、

  • チームは、他の優先事項 (場所、顧客など) によっても編成されます。
  • ツールは、他のターゲット (互換性、価格、ほとんどの従業員による使いやすさ) によっても選択されます。
  • 一部のツール (したがって、そこにあるバイナリ ファイル) は避けられません。なぜなら、同じ価格で企業のニーズに同じように適合する、同じ仕事を実行できる代替品がないからです。

会社全体がワークフローを再編成し、バイナリを生成するすべてのツールを置き換えて、ロックがないために git で作業できるようにするように要求するのは、非常に非効率に聞こえます。

ロックは git の哲学 (バイナリ用に作成されたことはありません) には適合しませんが、ロックがそのような問題を解決する最も効率的な方法であるという無視できない状況があります。

于 2016-05-18T07:31:32.733 に答える