当我提交 --amend 时，如果提交已经被推送到远程存储库，则它是不安全的提交。
我想通过预提交钩子和中止来检测不安全的提交——修改。
但是预提交钩子没有参数。我不知道如何检测--amend。
我应该怎么办 ？
问问题
5707 次
5 回答
13
遵循@Roger Dueck 的回答，最终做了：
#./.git/hooks/prepare-commit-msg
IS_AMEND=$(ps -ocommand= -p $PPID | grep -e '--amend');
if [ -n "$IS_AMEND" ]; then
return;
fi
于 2019-07-09T14:56:03.610 回答
7
TL;DR 版本：下面有一个脚本（有点在中间），它强制执行可能对您有用或可能不适用的特定工作流程。它并不能完全阻止特定git commit --amend的 s（而且您总是可以使用它--no-verify来跳过脚本），并且它确实阻止（或至少警告）其他git commits，这可能是您想要的，也可能不是您想要的。
要使其出错而不是警告，请更改WARNING为ERROR并更改sleep 5为exit 1.
编辑：错误输出不是一个好主意，因为在这个 git 钩子中你不能说这是一个“修改”提交，所以--no-verify如果你只是添加一个新的，这将失败（你必须添加）提交到具有上游并且位于上游头部的分支。
它不一定是不安全的，因为git commit --amend实际上并没有更改您的 repo 中的任何提交，它只是添加了一个新的、不同的提交并将分支提示重新指向那里。例如，如果您的分支如下所示：
A - B - C - D <-- master, origin/master
\
E - F <-- HEAD=branch, origin/branch
那么一个成功者git commit --amend所做的是：
A - B - C - D <-- master, origin/master
\
E - F <-- origin/branch
\
G <-- HEAD=branch
你仍然有 commit F，而 commitG是F. 但是，这确实G不是“快进”，在这种情况下F您可能不应该git push -f origin branch这样做。
如果您已经处于这种情况，也会发生类似的情况，即在成功之后git commit --amend（在没有或尽管有以下脚本的情况下完成）：
A - B - C - D <-- master, origin/master
\
E - F <-- origin/branch
\
G <-- HEAD=branch
如果你现在git commit（即使没有--amend），你将添加一个新的提交，例如，G连接到H; 但同样，尝试推动H是一种非快进。
您不能专门测试--amend，但您可以检查是否存在“上游”，如果有，当前是否HEAD是该上游的祖先。这是一个稍微俗气的预提交钩子，它可以做到这一点（带有警告和睡眠而不是错误退出）。
#!/bin/sh
# If initial commit, don't object
git rev-parse -q --verify HEAD >/dev/null || exit 0
# Are we on a branch? If not, don't object
branch=$(git symbolic-ref -q --short HEAD) || exit 0
# Does the branch have an upstream? If not, don't object
upstream=$(git rev-parse -q --verify @{upstream}) || exit 0
# If HEAD is contained within upstream, object.
if git merge-base --is-ancestor HEAD $upstream; then
echo "WARNING: if amending, note that commit is present in upstream"
sleep 5:
fi
exit 0
这里的基本问题是，即使不使用git commit --amend. 假设您从与上面相同的设置开始，但提交F还不存在：
A - B - C - D <-- master, origin/master
\
E <-- HEAD=branch, origin/branch
现在你，在你的 repo 副本中，决定处理branch. 您修复了一个错误并git commit：
A - B - C - D <-- master, origin/master
\
E <-- origin/branch
\
F <-- HEAD=branch
你现在领先origin并git push origin branch会做正确的事。但是，当您修复一个错误时，乔在他的 repo 副本中修复了一个不同的错误，并将他的版本推送到origin/branch，从而使您领先push一步。所以你跑去git fetch更新，你现在有了这个：
A - B - C - D <-- master, origin/master
\
E - J <-- origin/branch
\
F <-- HEAD=branch
（J乔的承诺在哪里）。这是一个完全正常的状态，如果能够git commit添加另一个修复（例如，第三个错误），然后合并或变基以包含 Joe 的修复，那就太好了。示例预提交挂钩将反对。
如果你总是先rebase-or-merge ，然后添加第三个修复，脚本不会反对。让我们看看当我们进入上面的F-and-J情况并使用git merge（或git pull进行合并）时会发生什么：
A - B - C - D <-- master, origin/master
\
E - J <-- origin/branch
\ \
F - M <-- HEAD=branch
您现在处于 commit M，即“领先于”的合并中J。所以脚本会@{upstream}找到 commitJ并检查HEADcommit ( M) 是否是J. 不是，并且允许进行额外的新提交，因此您的“修复第三个错误”提交N会为您提供：
A - B - C - D <-- master, origin/master
\
E - J <-- origin/branch
\ \
F - M - N <-- HEAD=branch
或者，您可以git rebase进入J，以便在修复第三个错误之前：
A - B - C - D <-- master, origin/master
\
E - J <-- origin/branch
\ \
(F) F' <-- HEAD=branch
（这里F'是精心挑选的提交F；我用括号F表示，虽然它仍在你的仓库中，但它不再有任何指向它的分支标签，所以它几乎是不可见的。）现在预提交钩子脚本不会'再次反对。
于 2013-10-15T19:13:57.030 回答
4
在预提交挂钩中检测“纯”修改的快速方法：
if git diff --cached --quiet ; then
echo "This is a pure amend"
else
echo "This is a commit with changes"
fi
“纯”是指您只是重写提交消息，而不是提交中的任何更改。如果您在git commit --amend调用git commit.
于 2017-02-01T17:41:35.660 回答
2
按照@perror的回答，我想出了以下内容：
parent=$(/bin/ps -o ppid -p $PPID | tail -1)
if [ -n "$parent" ]; then
amended=$(/bin/ps -o command -p $parent | grep -e '--amend')
if [ -n "$amended" ]; then
echo "This is an 'amend'"
fi
fi
于 2019-06-27T21:19:24.077 回答
0
--amend在标准外壳中检查是否是这种情况的另一种方法：
git_command=$(ps -ocommand= -p $PPID)
if [ -z "${git_command##git\ commit*--amend*}" ]; then
echo "The original command was a: git commit --amend"
exit 0
fi
于 2019-06-24T13:50:00.273 回答