git在pre-push hook中提交

laj*_*rre 17 git githooks

我在pre-push钩子中添加了类似的东西:

gs0=$(git status)
pip-dump
gs1=$(git status)
if [ "gs0" != "gs1" ]
then
    git commit -m "pip-dump"
fi
Run Code Online (Sandbox Code Playgroud)

(这是更新我的点数要求文件)

看起来推送不是推动新提交,而是HEAD在脚本开头的时候.

如何解决?

tor*_*rek 21

你不能:push命令在调用钩子之前确定哪个提交要推送,如果钩子退出0则推送它.

我看到三个选择:

  1. 退出非零,告诉用户"推送被拒绝,因为我添加了提交"
  2. 退出零,告诉用户"推送已完成,但您需要再次推送,因为我添加了提交"
  3. 在添加新提交之后,在钩子内做另一个(不同的)推送,注意你的钩子不会无休止地递归,因为"内部"推动运行钩子,决定做另一个"内部再次"推动等.然后,在宣布你必须进行"内部"推送以获得额外提交后,退出非零,中止"外部"推送.

我个人的偏好是第一个.预推钩意味着 "验证此推送是否正常"操作,而非"改变此推动意味着某些其他不同的推动"操作.这意味着你不会违背软件的"意图".使用预推钩作为验证器; 如果您需要git push在需要时自动添加pip-dump提交后调用的脚本,请使用其他名称将其写为脚本,例如dump-and-push.

  • 我认为选项1是最好的。但是`dump-and-push'解决方案对我不好,因为我对自己或我的团队没有信心不要忘记不使用`git push`。 (2认同)
  • 好吧,在因为需要转储而拒绝推送时,您可以发出一行信息,“顺便说一句,如果您使用此其他脚本,它将正常工作,这会更容易吗?提示提示!:-)” (2认同)
  • @ AD7six有一个好处:如果你真的想要强制执行,你需要在集中式服务器上使用预接收或更新挂钩. (2认同)
  • 谢谢@torek!在每次自动管理版本之前,我需要运行“ npm version patch”。因此,我使用选项1,效果很好!https://github.com/wechaty/wechaty/blob/8a32376b07e53ea28e694a2d854af00e2b426d9e/bin/pre-push (2认同)
  • 对于选项3,您可以在脚本中调用`git push --no-verify`来进行推送,而无需再次调用挂钩 (2认同)