Gitには、コンテンツが完全に異なるブランチを追跡（およびクリーンに）する機能があるため、同じリポジトリ内で、一部のプロジェクト（Git自体など）がそれを利用し始めています。
たとえば、Gitはコード自体に1つのブランチを使用し、ドキュメントは別のブランチに保持します。同じリポジトリ、異なるブランチ。
SVNのバックグラウンドから来たのは私だけかもしれませんが、これらのブランチに「共通点がない」と混乱します。開発/ステージング/本番ブランチ。私が理解しているもの。不完全な機能のブランチ。確かに、私もそうしています。ちなみに、言語ごとに1つのブランチを持つドキュメントを用意してください。しかし、共通のファイルはありませんか？
これはGitの単なる（おそらく十分に活用されていない、および/または市場に出回っていない）機能であり、誰もが受け入れて慣れるべきものですか、それとも同じプロジェクトの2つの側面を十分に区別しないことに怠惰な誰かによる危険な誤用ですか？
個人的には、異なるブランチに異なるコンテンツを保存することはありません。ドキュメントとコードの場合、myproject.git と myproject-docs.git を作成します (ビルド プロセスに必要な場合は、ドキュメントをコードにサブモジュール化します)。
一方、これを行うと、悪いことは何も起こりません。Git は何をすべきかを教えてくれるわけではないので、Git をどのように使用するかは自由に決めることができます。あなたの質問に答えるために、それはキラー機能でも、注意しないとあなたを圧倒するようなものでもありません. それは、誰かがそれを使用することを選択した方法です。
Gitは、プロジェクト内の（テキスト）ファイルの調整された変更を追跡するため、ブランチがマージ可能かどうかを認識または気にしません。Gitリポジトリに独立したブランチを持つことは、Subversionリポジトリに独立したプロジェクトを持つことに似ています。これは一般的な方法です（svnのオーバーヘッドのため）。
Gitのデータ構造はSVNのデータ構造とは大きく異なるため、Gitを使用してさまざまなことを行うことができます。SVNでは、機能ブランチはやや珍しく、トランクにマージされないことが多い機能ブランチは「悪臭」である可能性があります。これは、プログラマーが「暗くなった」ことを示し、決して不可能なコードを作成していることを示しています。プロジェクトに統合されました。Gitでは、機能ブランチは完全に安全で賢明なワークフローです。
したがって、Gitはリポジトリとブランチとコミットの両方を備えていてもSVNではなく、ソース管理の同じ一般的な機能を提供するため、さまざまな方法で使用できます。
Gitの経験を積むにつれて、奇妙だったものが変わってきました。それから、私はその別のツールで何ができるかについて興味を持ちました。
Gitは現在、同じリポジトリに複数のプロジェクトを保存することを処理できないという事実に対する、怠惰な回避策のようなものだと思います。あなたはそれをすることができます、しかしあなたが望むものだけを引き下げる方法はありません。
私は「怠惰な」と言います。なぜなら、git開発者自身が（ドキュメントを保存するために）その必要性を発見したときに機能を追加するのはそれほど難しくなかったからです。彼らはこの奇妙なブランチハックを使用したので、他のすべての人のために問題を修正するという彼らのインセンティブは大幅に弱まりました。
それはあなたのプロジェクトが何であるかによると思います。
Gitは明らかにコミュニティOSSプロジェクトであるため、（同じ）リポジトリにドキュメントを配置して、誰もがそれらを取得できるようにすることは（私にとって）理にかなっています。
一方、「ドキュメントを更新しましょう」タイプのチケットを除いて、プロジェクトのドキュメントをrarleyで編集するので、プロジェクトのドキュメントは保存しません。仕事では、ドキュメントをソースと混同したくありません。ソース（私が知っている典型的なプログラマービュー）だけが必要です。
他の人はそれらを一緒に欲しがるかもしれません。それが何を意味するのかを理解し（誰もがリポジトリの完全なコピーを持っていることを忘れないでください）、プロジェクトに最適なオプションを選択する必要があると思います。
これを行う利点は、興味がある場合は docs ブランチのみをプルできることです。jrockway が言ったように、必要に応じて別のリポジトリとサブモジュールを使用してこれを行うことができますが、この機能を使用して「裸の' 分岐しないオプションがあります。
個人的には、私はまだこれについてフェンスにいます。それが有益である理由は理解できますが、それが最善の方法であると完全に確信しているわけではありません。
ツリーをユーザーに提示するSubversionモデルに慣れている場合は少し奇妙ですが、モデルに慣れれば、混乱ははるかに少なくなります。
gitリポジトリは、ディレクトリをある状態から別の状態に変換する方法を説明するオブジェクトのツリーです。これらのオブジェクトには親があります。一部のオブジェクトには2つ（またはそれ以上）の親があります。マージします。一部のオブジェクトには親がありません。最初のコミット。
私が理解しているように、内部的には、Subversionのモデルは、マージがどこから来たのかという概念を除いて類似しています。svn mergeこれらは、他の2つのコミットの違いのパッチを取得するための便利なコマンド（）を使用した新しいコミットです。
私は実際にこの機能をかなり頻繁に使用して、のような別々のホスト上の同じディレクトリから開始された構成ファイルを管理します/etc/apache2。「これはこのようなものの代替の始まりですが、それは放棄されました」と言っているようなものです。これにより、ファイルを上書きする前にいくつかのファイルの状態を隠しておくことができますが、それらが正しくマージされるかどうか、またはマスターブランチにまったく関連するかどうかを心配する必要はありません。
Subversionでは、そのバックアップを無関係な場所（zipファイルのどこか）またはリポジトリのサブディレクトリに格納する必要があります。さらに、Subversionでは、ツリーの現在のビューでこれらのファイルへの参照を削除すると、それらを再度見つけるのが非常に困難になります。