跨平台 git hooks
如何跨各种平台(例如,*nix 和 windows)管理 git 提交前/提交后挂钩?
针对这种情况有推荐的最佳实践吗?
How do you manage git pre/post commit hooks across various platforms (say, *nix and windows)?
Any best practices recommended for this scenario?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
git hooks 实际上与任何 shell 脚本没有什么不同,因为保持它们“跨平台”的最佳实践同样适用。细微的区别是,您也可能将 Windows *nix 模拟层作为这些钩子的主要用户,并且与大多数实际的 Unix 环境相比,这些可能会相对削弱。
我刚刚将一个提交后挂钩(并编写了一个预提交挂钩)移植到 Windows 的默认 Git,它使用 MINGW32。自从上一个版本对可用的脚本环境做了一些假设以来,我必须做出一些更改:
readlink
,但它在 Windows 上无论如何都是无效的,所以我只是侵入了readlink
的检查code>which readlink 和 no-oped if there was none/dev/null
在 Windows 中不起作用,而是必须重定向到nul
,为了做到这一点,我只是做了一个uname -s
检查并设置一个变量来重定向到mktemp
可用的目录,但由于它是一个目录,我们最终修剪了无论如何,出于某种原因,我们使用了天真的硬编码目录名称除此之外,它按原样工作得很好,因为其中没有很多特定于平台的“东西”它。因此,只要坚持制作跨平台脚本的最佳实践,这应该会让您至少完成 80% 的工作。之后,在您所针对的所有各种环境中进行测试测试。
The git hooks are really no different than any shell script in that the best-practices for keeping them "cross-platform" apply just the same. The minor difference is that you may also be targeting the Windows *nix emulation layers as major users of these hooks as well, and these can be comparatively crippled by comparison to most actual Unix environments.
I just ported a post-commit hook (and wrote a pre-commit hook) to the default Git for Windows, which uses MINGW32. A few of the changes I had to make since the previous version made some assumptions about the scripting environment available:
readlink
available, but it was ineffectual on Windows anyway, so I just hacked in a check ofwhich readlink
and no-oped if there was none/dev/null
doesn't work in Windows, instead you have to redirect tonul
, to do this I just did auname -s
check and set a variable for what to redirect tomktemp
available, but since it was a directory that we ended up pruning anyway, we used a naively hard-coded directory nameexec >>$out
works fine in MINGW32, butexec 2>>$err
for STDERR does not (it seems to die silently), so unfortunately we just had to eschew that redirectionOther than that, it worked pretty well as-is because there wasn't a lot of platform-specific "stuff" in it. So just stick to best practices for making cross-platform scripts and that should get you at least 80% of the way there. After that, test test test in all of the various environments you're targeting.