在 mac OS 上从 crontab 发出运行 git pull 命令

Question

我正在尝试使用 crontab 自动运行 git pull 命令。 我在 MacOs 机器上。 Git 当我在没有 cron 的情况下使用它时，pull 工作正常，但在 cron 中出现错误。 我已经尝试了各种解决方案。 其中一些在下面。 他们都手动工作正常。

我尝试将以下命令放入脚本 automate.sh 中，然后使用 cron 运行它。

1. ssh-agent bash -c 'ssh-add /Users/{username}/.ssh/id_rsa; /usr/bin/git pull'

2. eval `ssh-agent -s` && ssh-add ~/.ssh/id_rsa && ssh-add -l && git pull

但我总是低于错误，

fatal: could not read Username for 'https://git.{domain}.com': Device not configured

为什么？

Answer 1

我认为问题在于您需要的引号。 尝试在没有括号的变量周围使用双引号( {} )

ssh-agent bash -c 'ssh-add /Users/'"$username"'/.ssh/id_rsa; /usr/bin/git pull'

注意：变量domain相同

看看这个问题

Answer 2

TL;DR：如果可以，请使用 ssh URL。 （并且：不要从脚本运行git pull 。）

您在此处显示的URL ，来自您的错误消息：

https://git.{domain}.com

不是ssh （安全外壳）URL。 它是一个 HTTPS (HTTP-over-SSL) URL。 这是两种完全不同的协议。 它们通常在不同的 IP 端口上运行（ssh 为 22，https 为 443）。 并非所有 Git服务器都响应这两种协议，但如果您的服务器响应，则您的 Git 作为客户端存在两个关键差异：

• Git 作为客户端，通过https://连接，必须向服务器提供两项：用户名和密码。 （密码不必是文字密码，例如可以是 PAT。）

• Git 作为客户端，通过ssh://连接，必须向服务器提供两项：用户名和某种密钥。

除了“密钥”与“密码”，它们看起来——实际上——非常相似，但 https 和 ssh 客户端以完全不同的方式获取这两个项目：

• https 客户端通常直接从用户的键盘读取用户名和密码，绕过所有重定向尝试。

• ssh 客户端通常将用户名作为参数，并从公共和/或私有密钥对文件中读取密钥和/或从代理获取密钥。

这两个要点中的单词通常做了很多繁重的工作，但这就是您看到的错误的原因。 当您从 cron 作业运行git pull ，没有键盘可以读取. 这是物理不可能的cron -这，而你甚至在不是可运行的计算机有你的用户名和密码输入。 在 Mac 上尝试打开/dev/tty导致Device not configured错误。

收到该错误后，libCURL 库¹放弃并且整个拉取失败。

现在，请注意ssh从参数中获取用户名——而不是让你输入它——并从文件和/或ssh 代理中获取密钥，而不是让你输入它。所以 ssh 已经非常强大了这里的优势：它不需要您坐在键盘前，准备好需要输入用户名和密码。 因此，如果您让 Git 使用 ssh, ²您更有可能继续。

这不是答案的结束（尽管这是开始，因此是上面的 TL;DR）。 使用 https 时，您可以告诉 libCURL不要从用户那里读取用户名和密码。 具体如何操作取决于操作系统，但一般来说，您可以使用以下形式的 URL：

https://user@host:password/path/to/repo.git

这样做的缺点是您将用户名和密码以明文形式放在那里供所有人查看。 避免这种情况，除非这是您唯一的选择。

或者，Git 可以使用凭据助手将用户名和密码提供给libCURL。 这是关于 Git 的另一个大秘密： Git根本不进行任何身份验证。 如果你想声称自己是 Barack Obama， ³你可以继续这样做， Git 会相信你的。

它是其他程序进行身份验证。 Git 依赖于这些其他程序（尤其是 Web 服务器和 ssh 服务器）进行身份验证； 这决定了您可以在其他机器上读取和写入哪些存储库。 在您的本地机器上，本地操作系统的权限决定了您可以读写哪些存储库。

由于 ssh 有自己的相当大且复杂的方法来处理身份验证（包括 ssh 代理），因此我们在这里根本不会介绍它，但我将谈谈使用 libCURL 的凭证助手。 Git 总是有两个简单的， store和cache ： store助手只是将用户名和密码保存在一个文件中（它不加密，所以考虑避免这种情况，或者至少，小心保护这个文件）。 cache助手不会永久存储凭据，而只是临时存储，因此危险性较小，但它意味着要卡在其他助手的前面。 另一个助手可能需要密码，为了避免每次都输入密码，您可以将缓存助手放在中间：如果缓存条目已过期，缓存助手将从下一级助手获取密码，现在您必须输入密码； 但除此之外，它会传回缓存的条目，以便您这次不必键入它。

用于各种操作系统的 Git 附带了额外的特定于操作系统的帮助程序。 特别是在 OSX 上，有一个使用 OS X Keychain 软件的git-credential-osxkeychain助手。 （我不使用这个：我使用 ssh。）

有关所有这些的完整说明，请参阅gitcredentials 文档。 某些特定帮助程序何时以及是否适用于您的特定 https 设置取决于太多因素，无法在这里猜测。

---

¹ Git 没有内置所有的 https 协议； 相反，Git 只是链接到 libCURL。 操作系统的 libCURL 依赖于操作系统，因此这有助于 Git 避免过于依赖操作系统。

²当使用 ssh URL 时，Git 也只是运行 ssh。

³如果你真的是巴拉克奥巴马，你为什么要读这个？

---

关于git pull

git pull命令做了两件事：

1. 首先，它运行——或尝试运行—— git fetch 。 这会连接到其他一些系统并获得新的提交，或者，在您的情况下，连接失败（然后停止git pull跟踪）。

2. 如果在第 1 步中一切顺利， git pull现在运行第二个 Git 命令。 您提前选择是git rebase还是git merge 。

命令#2旨在以交互方式工作。 无论您选择哪个命令，Git 都会尽力结合您所做的任何工作，在您的存储库中进行新的提交，以及在获取步骤（命令 #1）期间进入的任何新提交。 这可能需要用户帮助。 如果是，命令 #2 会打印关于需要什么帮助的消息，并以错误状态终止，在您的 Git 存储库中留下一团糟。 在您尝试进一步操作之前，必须清除这些混乱。

因为我们首先不知道命令 #2是否会成功，所以在无人值守的脚本中使用git pull总是一个坏主意。 我们可以猜测命令 #1 是否可能成功，并在脚本中检查它，所以在脚本中使用git fetch是可以的。 但是，在任何无人值守的脚本中使用git rebase或git merge永远都不好，除非您的脚本检查失败并安排一些有用的事情发生（提醒人类，停止尝试进一步的命令，等等）。

要在脚本中正确执行所有这些操作，您必须将git pull分解为其组成步骤，因为git pull失败可能意味着：

• 获取失败：可能是暂时的网络故障； 没什么大不了; 请稍后再试！
• 第二步失败：灾难！ 不要继续。

您需要知道发生了哪些，因此您不能使用git pull 。