git deps
1.0.0
git-deps是用于对GIT存储库中提交之间依赖关系进行自动分析的工具。这是屏幕截图演示：
我已经写了有关git-deps和相关工具的博客，并多次公开谈论该工具：
很明显，单个回购中的两个git提交在某种意义上可以将彼此视为“独立”，如果它们不更改相同的文件，或者如果他们不更改同一文件的重叠部分（s）。
相比之下，当提交更改线路时，它不仅取决于上次更改该行的提交，而且还取决于任何负责提供周围环境行的提交，因为如果没有该行的那些以前的版本及其上下文，则提交的diff可能不会清晰地应用（当然要根据其应用程序的应用方式）。因此，可以通过编程中的所有依赖性在“提交”变化的行上进行编程来推断，但是对于此特定依赖性分析的用例，许多上下文行是有意义的。
因此，依赖性计算受“ fuzz”因子参数（cf patch（1））的影响，即上下文的线数被认为是通信差异所必需的。
与许多依赖关系一样，这些依赖关系在dag（有向无环图）中形成边缘，其节点与提交相对应。请注意，节点只能取决于其祖先的子集。
重要的是要意识到， git-deps推断的任何依赖图在语义上可能是不完整的。例如，它不会在更改代码的提交A与另一个提交b之间自动检测依赖关系，该依赖性是更改文档或测试以反映CONTE的代码更改A中的A。因此， git-deps不应以盲目的信念使用。有关更多详细信息，请参见下面的文本和语义（IN）依赖性的部分。
有时，了解该依赖图的各个部分的性质很有用，因为它的性质会影响操作的成功或失败，包括合并，rebase，cherry，挑选樱桃等。请参阅USE-CASES.md文件以获取更多详细信息。
请参阅INSTALL.md文件。
请参阅USAGE.md文件。
敏锐的读者会注意到， git-deps检测到的文本独立性与语义 /逻辑独立性不同。文本独立性意味着可以在任何顺序上应用任何更改而不会产生冲突，但这不是逻辑独立性的可靠指标。
例如，对功能的更改以及对该功能的测试和/或文档的相应更改通常存在于不同的文件中。因此，如果这些更改是在分支机构内的单独提交中，即使它们在逻辑上相关，在提交上运行git-deps也不会检测到它们之间的任何依赖性，因为不同文件（甚至在同一文件的不同区域中）在文本上是独立的。
因此，在这种情况下， git-deps不会确切地表现我们可能想要的方式。只要AI是一个未解决的问题，它就不可能发展出完全可靠的行为。那么这是否意味着git-deps是没有用的？绝对不是！
首先，当遵守提交结构的最佳实践时，无论如何，在逻辑上与逻辑上密切相关的更改无论如何都应在同一提交中。因此，在上面的示例中，对函数的更改以及对该功能的测试和/或文档的相应更改都应在单个提交中。 （尽管这不是唯一的有效方法；对于更高级的元历史组合机制，请参见git-dendrify 。）
其次，尽管文本独立性并不意味着逻辑独立性，但预期相反的独立性是更常见的：逻辑独立性通常意味着文本独立性（或以另一种方式说明，文本依赖性通常意味着逻辑依赖性）。因此，尽管git-deps无法检测到与逻辑相关的变化之间的依赖关系可能并不少见，但它应该更罕见，它会错误地渗透在逻辑上无关的更改之间的依赖性。换句话说，通常期望其假否定性比其假阳性更普遍。结果，与上限相比，它在确定依赖关系的下限时可能更有用。话虽如此，需要更多的研究。
第三，让寻求完美成为善良的敌人通常是无济于事的 - 工具不必是完美的才能有用；它只需要比没有工具执行相同的任务更好。
有关其中一些要点的进一步讨论可以在GIT邮件列表中的旧线程中找到。
最终，“证明在布丁中”，所以请尝试一下！
请参阅CONTRIBUTING.md文件。
请参阅HISTORY.md文件。
特别感谢Suse部分赞助该软件的开发。还要感谢所有贡献代码，错误报告和其他反馈的人。
根据GPL版本2发布，以与git的许可一致，但是如果有令人信服的原因，我对双重许可的想法开放。
