自动检测git提交之间的依赖关系
git-deps的Python项目详细描述
git deps
git deps是一个执行依赖项自动分析的工具 在git存储库中的两次提交之间。这里有一个 屏幕广播演示：
我还在《GitMinutes》第32集中谈到了这个工具。 播客
背景理论
很明显，一个repo中的两个git提交可以是 在某种意义上被认为是相互独立的 不更改相同的文件，或者如果它们不更改 相同的文件。
相反，当提交更改行时，它不仅依赖于 上次更改该行的提交，以及 负责提供周围的上下文行，因为 如果没有先前版本的行及其上下文， commit的diff可能无法完全应用（取决于它是如何应用的 当然是申请的）。所以提交的所有依赖项都可以是 通过在提交的行上运行git-uncoul以编程方式推断 变更，再加上许多上下文行对于用例来说是有意义的 这个特殊的依赖性分析。
因此依赖性计算受到"fuzz"因素的影响 参数（C.F. 修补程序（1） ，即 被认为是 提交差异以干净应用。
与许多依赖关系一样，这些依赖关系在 一种dag（有向无环图），其节点对应于提交。注释 节点只能依赖于其祖先的子集。
动机
有时了解这个DAG的某些部分的性质是有用的，如 其性质将影响运营的成败，包括 合并、重新定位、樱桃采摘等。
用例1：分支之间的移植
例如，当通过 git cherry pick ，以编程方式确定 提高其他从属提交的最小数量，这也将 需要精心挑选以提供提交"a"到的上下文 干净地涂抹。这是一个快速演示！
用例2：分割修补程序系列
对于项目来说，大的补丁系列或拉取请求可能非常令人望而生畏。 维修人员，因为他们很难一下子征服。为此 通常最好保持 提交量相当小。但是在正常的黑客攻击中，你可能 在你开始思考之前积累大量的补丁 向上游提交其中任何一个。在这种情况下，git deps可以帮助您 决定如何把它们分成小块。只需运行
git deps -e $upstream_branch -s
然后创建从本地开发负责人开始绘制图表 分支，递归扩展所有依赖项。这会让你 解开事物并公开可以清楚地分开的子图 分为单独的修补程序系列或请求提交。
用例3：帮助协作通信
另一个用例可能是更好地理解专业化水平/ 敏捷团队中的跨功能性。如果我提交了 修改（比如）文件的第34-37行和第102-109行 从属提交形成一个列表，指示 应该考虑重新考虑我的承诺，因为我 有效地改变他们的代码。监视这些关系 时间可能会让我们了解敏捷团队应该如何最好地协调 在共享代码基础上的努力。
警告
注意依赖关系图可能在语义上不完整；对于 例如，它不会自动检测 更改代码和另一个更改文档或测试的提交B 以反映commit a中的代码更改。 通常最佳实践是在 但这不应阻止它发挥作用。
其他用途
我确信还有其他的用例我还没有想到。如果你有 任何好的想法，请提交！
非使用案例
起初，我认为git deps可以提供一种有用的方法 以编程方式预测诸如merge/rebase之类的操作/ 樱桃采摘会成功的，但实际上它可能更便宜 可靠，只需执行操作然后回滚即可。
安装
请参阅 the``install.md` 文件<；install.md>；``uu.
用法
这个工具还没有完全的文档化，但是使用是公平的 如果运行 git deps -h
目前，您应该从 要检查的git存储库；这是已知的 限制
默认情况下，它将输出给定提交ish的所有依赖项， 每行一个。使用递归，它将遍历 依赖关系等等，直到找不到为止。递归中 模式，每行输出两个SHA1，表示第一个取决于 在第二天。
用于可视化和导航依赖关系图的Web UI
如果您使用 --serve选项运行，那么它将启动一个轻量级 webserver并输出一个可以动态连接的url 可视化和导航依赖关系图。
（可选）选择提交ish（表单默认为 master ），单击 submit 按钮，您将看到一个带有一个节点的图形 每次提交。将鼠标悬停在节点上，您将看到更多详细信息， 会出现一个小的图标，可以点击来计算 提交的依赖项，进一步扩展依赖树。你 可以使用鼠标滚轮放大和缩小，并拖动背景进行平移 周围.
如果在 设置， 如文档所示 您可以双击 在节点上启动查看器以检查 细节，
开发/支持/反馈
请参见contributing.md" rel="nofollow">贡献文件
历史记录
这个工具诞生于 2013年，当我试图帮助 同事在OpenStack中备份一个错误修复程序 nova 来自 主节点 分支到稳定释放分支。乍一看它像 只需要一个很小的小齿轮，但是马上就可以了 由于在 master中更改了相关代码而显示的冲突 自从释放之后。我手动找到了下面的提交 使用git-buncy所需的错误修复，并尝试了另一个 樱桃采摘器。同样的事情又发生了。很快我发现自己 在提交之间的依赖性的泥潭中，不知道 结束在望。
在接下来的opensuse会议期间的咖啡休息时间 地点，我狂热地砍掉了一个原型，它似乎工作了。 然后，正常的生活就介入了，一年也没有任何进展。
感谢SuSE慷慨的"黑客周" 政策上，我有幸能在一月初度过一段时间 2015年致力于将这一工具提升到新的水平。我提交了一份 周项目页和 在"git"上宣布了我的意图 list<； http://article.gmane.org/gmane.comp.version-control.git/262000 >；`\uu.
2018年5月，我又利用另一个黑客周打包 为了改进 安装过程。这是为了演示 软件，网址：Meetup 事件 Git London用户组
许可证
在GPL版本2下发布，以便保持一致 用git 许可证<； https://github.com/git/git/blob/master/copying 如果有令人信服的理由，欢迎双重许可的想法。
欢迎加入QQ群-->： 979659372
