ワークフロー：ロックなしでGitでバイナリドキュメント形式を使用する（subversionから移動）

私たちは、さまざまな顧客向けの多数のプロジェクトを持つソフトウェアコンサルタントです。従来はSubversionを使用していましたが、現在Gitへの移行を検討しています。

私たちが作成するドキュメントの大部分はお客様と共有されており（要件、グローバル設計、テスト仕様など）、MS Officeを使用してこれらを作成しています。Subversionでは、「ロック」機能を使用して、同じドキュメントを同時に編集しているユーザーがいないことを確認できます。Gitでは、分散型の性質上、gitにはロックがないため、これを行うことはできません。

ロックは実際には通信メカニズムにすぎませんが、非常に効果的なものです。

現在、私たちのコードと顧客向けのドキュメントは通常、異なるsvnリポジトリの異なるサブフォルダーにあります。gitに移行するときに、私たちが推奨することは何ですか？オプションのセットが表示されます：

1. svnリポジトリをgit 1-on-1に移動します。Officeファイルでロックを使用する代わりに、gitの人々が提案することを行い、何らかの方法でワークフローを変更して修正します。これは、ドキュメント編集のブランチで機能し、オーバーレビューをマージする可能性があります。このアプローチは、プロジェクト管理情報を含むExcelシートなどを分割します。チームメンバーは簡単に編集できますが（これを行うことをお勧めします）、正式なレビュープロセスの対象ではありません

2. コードにはgitを、ドキュメントとプロジェクト管理にはsvnを使用します。これには、よりデザイン性の高い特定のドキュメントが仕様のコードの「近く」にないため、更新を忘れる可能性が高くなるという欠点があります。さらに、誰もが2つのツールセットを使用して理解する必要があります。とはいえ、これはおそらく、顧客と向き合っていない設計ドキュメント用のテキストベースのドキュメントツール（ラテックス、マークダウン、HTMLなど）に移行する絶好の機会です。

3. 1に似git lockていますが、svnロックが行うことを行うコマンドをハックします（読み取り専用フラグを適切に切り替え、何らかの手段でサーバーと同期します）。

DVCSでロックが機能しないという議論は、あなたが完全にオフラインのときでもシステムが機能するはずだからです。SVNロックもオーバーライドできます。それらは通信メカニズムです。なんらかのネットワーク接続がなければ、コンピューターはあまり通信できません。

私svn lockたちのワークフローにどの程度適合しているかに非常に満足しているお店は私たちだけではありませんよね？

アイデアやヒントはありますか？

/programming/119444/locking-binary-files-using-git-version-control-systemが見つかりましたが、議論はかなり技術的なものです。2人のチームメンバーが同じバイナリファイルを同時に編集するという実際的な問題を解決または回避する方法を探しています。

次の2つの理由から、MS OfficeドキュメントのSVNを使用することをお勧めします。

1. それはすでにそこにあり、（私の意見では）Officeドキュメントを保持するのに適しています（こちらをご覧ください）。これを行うためのサードパーティ製ツールがはるかに多くあります。
2. ロックは、Gitで実現できますが、「Gitのような方法」ではありません。これらの機能が必要な場合は、最適なソリューションを提供するツールを使用してください。

私が好きなことわざには、「ハンマーを持っていると、すべてが釘のように見える」というようなものがあります。コードを保持するためにGitに移行しているからといって、ドキュメントを保持するためにGitを使用する必要があるという意味ではありません。

コードバージョン管理は、Officeファイルをバイナリで操作するのに最適なツールではありません。これらのツールはファイルレベルの変更で機能するためです。

MediaWiki（無料）やAtlassian Confluence（有料）などのコラボレーションツールを使用して、Word文書を簡単に抽出できます。または、LaTexを使用してOfficeファイルを生成します。

拡大させてください...

コラボレーションが必要な場合は、ファイルなどのユニットへの変更（単語の変更、言い換え、フォントの変更など）を強調するモデルを採用する必要があります。

SVNとGitは、コードについて考えても、テキストコンテンツによってファイルを比較する低レベルのツールです。しかし、問題は、高度な修正モデルを抽出するためにファイルの性質/内容を気にしないため、テキストファイルでのみ機能することです。

明確な例は画像ファイルです。けれどもTortoiseMergeのが彼らの本当の変更のための画像を比較することにより、SVNのユーザーを支援するツールです、通常のVCSESは、コンテンツが運営パッチファイルを超えます。説明させてください。TortoiseMergeなどのツールは、2つのファイルのより複雑なHSV分析を実装する場合、画像ファイルの新しいバージョンが数ピクセル、または輝度だけ変更されることを通知できます。透かしを追加したり、カラーレベルを変更したりできます。画像ファイルを比較するツールは、適切な比較アルゴリズムを実装している場合に違いを強調します。しかし、あなたのクライアントに新しいファイルをチェックするために必須デルタを生成します。デルタは、削除される行とファイルに追加される行のセットです。バイナリファイルには、ペイロードに同様の文字が含まれていない場合は改行がありません\r\n。また、単一の文字を変更する場合は、デルタ全体に改行があります。

ここに問題があります。バイナリファイルは、すべてのリビジョンでファイル全体をほぼ置き換える可能性があるため、バージョン管理には適していません。MS Officeを使用してOfficeファイルを作成し、共同編集者がOpenOfficeで編集する場合を検討してください。OpenXMLファイルの圧縮アルゴリズムのわずかに異なるバージョンを実装している場合でも、ドキュメント内の単一のコンマを変更した場合でも、まったく異なるファイルになります。

コラボレーションソフトウェアはドキュメントをテキストベースの形式で内部的にレンダリングします。テキストは会社にとって本当に意味のあるものであり、差異を計算したり競合を処理したりできるからです。LaTex、または必要に応じてMarkdownは、ドキュメントを高度なマークアップ付きのテキストファイルとして保存する方法であるため、フォント/書式設定コントロールのない従来のTXTファイルとは異なります。

しかし、明らかに顧客はMarkdownファイルを開きたくないでしょうか？わかりました。簡単にできます。つまり、ソースドキュメントをPDF、Wordなどに変換するために、Googleにはあまりにも怠laなソフトウェアを使用するということです。

要約する

ソース管理へのテキストファイルのチェックを開始すると、ファイル履歴をより細かく制御でき、特にVCSロックを使用しなくても、競合を簡単に管理できます。

ドキュメントを公式に共有する前に、ソーステキストドキュメントをOfficeファイルにエクスポートするルーチンが必要です。

2つのステップを分離すると、学習曲線を犠牲にして人々を幸せにします。

ロックを追加せずにこれらのドキュメントにgitを使用できます。マスター上にない場合、マスターブランチへのプッシュをブロックするgitワークフローを選択します。（選択できるワークフローはいくつかあります。）これにより、バイナリドキュメントファイルに対する互いの変更が上書きされるのを防ぐことができます。2人が同じバイナリドキュメントを変更するとします。マスターにそれをプッシュする最初のものは変更を取得します。2番目のものはコピーがmasterブランチの背後にあるためブロックされます。最初に同期する必要があります。したがって、2番目の人は同期します。バイナリドキュメントのマージの競合が表示されます。その人はバージョンをどこかに保存し、マスター（最初の人によってプッシュされた）からバージョンを取得することで競合を解決します。この時点で、2番目の人のファイルはmasterブランチで最新です。変更を最新のバイナリドキュメントに（手作業で）マージし、最初の人の変更と2人目の人の変更の両方が含まれます。次に、新しいバージョンがマスターにプッシュされ、新しいマスターブランチになります。マージは苦痛ですが、競合がある場合にのみ発生します。また、変更が失われたり上書きされたりすることはありません。競合が検出され、ユーザーはそれらをきれいに解決できます。

最初の2つのソリューションをまとめると、3番目のソリューションは必要ありません。

スプレッドシートをCSVとしてディスクに保存する場合、Excelはそれらを編集します。その後、gitはそれらをマージします。

同様に、ファイルがHTMLまたはRTFである場合は、Wordでファイルを開いて編集し、保存できます。もちろん、Wordは有用なテキストよりも膨れ上がりますが、それでもgitがあなたに代わってマージしてくれるのはテキストだけです。

確かに、これらのソリューションは、Excel側の問題である可能性のあるMS固有の機能を使用しないか、または移行できないことを前提としています。

もちろん、ドキュメントを読むためにシステムにWordをインストールする必要もありますが、それ自体は恐ろしい見通しです...