git deps
1.0.0
git-deps GITリポジトリ内のコミット間の依存関係の自動分析を実行するためのツールです。スクリーンキャストのデモは次のとおりです。
私はgit-depsと関連するツールについてブログを書いています。また、このツールについて何度か公開されています。
同じファイルを変更しない場合、または同じファイルの重複部分を変更しない場合、単一のリポジトリ内で2つのgitコミットが互いに「独立」と見なされる可能性があることはかなり明確です。
対照的に、コミットが行を変更すると、最後にその行を変更したコミットだけでなく、周囲のコンテキストのラインを提供する責任のあるコミットにも「依存」します。これは、以前のバージョンのラインとそのコンテキストがなければ、コミットのDIFFがきれいに適用されない可能性があるためです（もちろん、適用される方法に応じて）。したがって、コミットのすべての依存関係は、コミットが変更されるラインでGit-blameを実行することでプログラム的に推測できます。さらに、この特定の依存関係分析のユースケースについては、多くのコンテキストが意味があります。
したがって、依存関係の計算は、「ファズ」因子パラメーター（CFパッチ（1））、つまりコミットの差分がきれいに適用されるために必要と見なされるコンテキストの行の数に影響されます。
多くの依存関係と同様に、これらの依存関係は、ノードがコミットに対応するDAG（指向の非環式グラフ）にエッジを形成します。ノードは、祖先のサブセットのみに依存できることに注意してください。
git-depsによって推測される依存関係グラフは、意味的に不完全である可能性があることに注意することが重要です。たとえばgit-depsコードを変更するコミットAと、ドキュメントまたはテストを変更してCODE AのCODEの変更を反映する別のコミットB間の自動検出依存関係はありません。詳細については、以下のテキストとセマンティック（in）依存のセクションを参照してください。
この性質は、マージ、リベース、チェリーピックなどを含む運用の成功または失敗に影響を与えるため、この依存関係グラフの一部の性質を理解することが役立つ場合があります。詳細については、 USE-CASES.mdファイルを参照してください。
INSTALL.mdファイルをご覧ください。
USAGE.mdファイルをご覧ください。
Stute Readersは、 git-depsによって検出されたテキストの独立性は、セマンティック /論理的独立性と同じではないことに注意してください。テキストの独立性とは、競合を伴うことなく変更を任意の順序で適用できることを意味しますが、これは論理的独立性の信頼できる指標ではありません。
たとえば、関数の変更とその関数のテストおよび/またはドキュメントへの対応する変更は、通常、異なるファイルに存在します。したがって、これらの変更がブランチ内で別々のコミットであった場合、異なるファイル（または同じファイルの異なる領域）の変更がgit-depsに独立しているため、論理的に関連しているにもかかわらず、コミットでGit-Depsを実行しても、それらの間の依存関係は検出されません。
したがって、この場合、 git-deps私たちがどのように望むかを正確に振る舞いませんでした。また、AIが未解決の問題である限り、完全に信頼できる行動を開発することはほとんどありません。それで、それはgit-depsが役に立たないことを意味しますか？絶対にそうではありません！
第一に、コミット構造のベストプラクティスが順守される場合、とにかく論理的に関連する強く論理的に関連する変更は、とにかく同じコミット内に配置する必要があります。したがって、上記の例では、関数の変更とその関数のテストおよび/またはドキュメントへの対応する変更は、すべて単一のコミット内にある必要があります。 （これは唯一の有効なアプローチではありませんが、より高度なメタ歴史グループ化メカニズムについては、 git-dendrify参照してください。）
第二に、テキストの独立性は論理的独立を意味するものではありませんが、逆はより一般的に真実であると予想されます。論理的独立性はしばしばテキストの独立性を意味します（または、テキスト依存はしばしば論理的依存を意味します）。したがって、 git-deps論理関連の変更間の依存関係を検出できないことはそれほど珍しいことではないかもしれませんが、論理的に無関係な変化の間に依存関係を誤って推進することはまれであるはずです。言い換えれば、その偽のネガは一般に、その誤検知よりも一般的であると予想されます。その結果、上限よりも依存関係の下限を決定するのに役立つ可能性があります。そうは言っても、これについてさらに研究が必要です。
第三に、完璧な人が善の敵になることを許すことはしばしば役に立たない - ツールは役に立つために完璧である必要はありません。ツールなしで同じタスクを実行するよりも優れている必要があります。
これらのポイントのいくつかに関するさらなる議論は、Gitメーリングリストの古いスレッドにあります。
最終的に、「証拠はプリンにある」ので、試してみてください！
CONTRIBUTING.mdファイルをご覧ください。
HISTORY.mdファイルをご覧ください。
このソフトウェアの開発を部分的に後援してくれたSuseに感謝します。コード、バグレポート、その他のフィードバックを提供してくれたすべての人にも感謝します。
gitのライセンスと一致するためにGPLバージョン2の下でリリースされましたが、説得力のある理由がある場合は、デュアルライセンスのアイデアを受け入れています。
