在某些情况下,您希望查找有关 Git 存储库中更改的信息,而无需克隆完整的存储库。这通常在您的自动构建环境中。当我使用 Jenkins、Travis 或 Circle CI 时,我可以访问克隆的 Git 存储库,并且可以毫无问题地使用git log、git ls-remote和git diff。

其他工具,我专门谈论 AWS CodeDeploy,采用不同的方法。 AWS CodeDeploy 没有让您访问克隆的存储库,而是为您提供了没有.git文件夹的代码快照。这使得无法检查自上次构建以来发生的变化,甚至无法确定触发构建的提交中发生了什么变化。一些 CI 环境会给你一个没有完整 Git 历史的“浅克隆”,给你留下类似的挑战。

我想运行这些检查以确定我们的 monorepo 中的哪些微服务发生了变化,因此我知道要构建和重新部署哪些微服务。这是在这篇Shippable 博客文章中很好地描述的技术。

我查看了两个选项来找出自上次成功部署以来发生变化的文件夹:

1. 在 CodeBuild 步骤中手动克隆完整存储库

2. 使用 GitHub API 检索有关提交的信息

第一个选项是我想避免的。这意味着在构建开始时克隆一个潜在的大型且不断增长的存储库。浅层克隆是不够的,因为它无法捕获回溯到先前版本的更改历史记录。

GitHub REST API 包括一个compare API和一个list-commits API。比较 API 限制为 250 次提交,因此不能依赖。 get-commits API 可以工作,但这意味着对大量数据发出多个分页请求,只是为了获取更改的路径。经过一番反复试验,我最终放弃了 GitHub API 方法。

在进一步挖掘之后,我发现了一个StackOverflow 帖子,它给了我第三个选项。它允许我使用git命令获取两个单独的提交,然后进行比较以确定更改的文件名。在此示例中,我使用的是公共lodash/lodash存储库。假设我们要比较标签4.0.0和master分支的HEAD之间的变化,命令序列如下所示:

git init .                                               # Create an empty repository
git remote add origin git@github.com:lodash/lodash.git   # Specify the remote repository

git checkout -b base                                     # Create a branch for our base state

git fetch origin --depth 1 4.0.0                         # Fetch the single commit for the base of our comparison
git reset --hard FETCH_HEAD                              # Point the local master to the commit we just fetched

git checkout -b target                                   # Create a branch for our target state

git fetch origin --depth 1 master                        # Fetch the single commit for the target of our comparison
git reset --hard FETCH_HEAD                              # Point the local target to the commit we just fetched

git diff --name-only base target                         # Print a list of all files changed between the two commits

进入全屏模式 退出全屏模式

使用这种最小获取方法的目录大小为 4.6M,而完整的lodash存储库为 49M。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--818RYP7P--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev. s3.amazonaws.com/i/6lwlrl204jw37ynpx67e.png)

我是fourTheorem的首席技术官。在推特上关注我:@eoins