一些背景:
我和CI系统有矛盾,因为它们是在拉请求时触发的,而不是在目标分支更新时触发的。
考虑两个没有合并冲突的拉请求,但它们之间存在逻辑冲突。每个测试都通过了CI push & pr测试。
第一个被合并为主人。现在,将第二个与主程序合并将导致一个逻辑问题。但是,没有合并冲突,CI状态表明我们可以继续,因为测试是在旧代码上运行的。
总之,它看起来很好,但却很糟糕。
我对修复程序的想法:
强迫冲突。在off母版的任何分支上,都有一个git-checkout钩子更新一个时间戳文件.现在,如果是下一次合并,时间戳可以合并到主服务器中,但它将与其他工作人员发生冲突。
现在,一个没有冲突并且通过CI构建的分支可以很好地运行。听起来对吗?
要求:
我需要一个钩子,更新时间戳文件,并在本地提交它的任何分支的主人。我该怎么做?
谢谢。
发布于 2016-10-12 18:51:21
这是一个脚本,似乎做了正确的事情。它还没有经过彻底的测试。
#!/bin/sh
# https://git-blame.blogspot.ca/2013/06/checking-current-branch-programatically.html
if BRANCH=$(git symbolic-ref --short -q HEAD)
then
ON_BRANCH=true
else
ON_BRANCH=false
fi
MASTER_SHA=`git show-ref --heads -s master`
PREV_SHA=$1
CURRENT_SHA=$2
WAS_CHECKOUT=$3
if [ "$WAS_CHECKOUT" == "1" ] && [ "$MASTER_SHA" == "$CURRENT_SHA" ] && $ON_BRANCH && [ "$BRANCH" != "master" ];
then
STAMP="$(git rev-parse --show-toplevel)/.stamp"
echo "$(date +%Y-%m-%d:%H:%M:%S) - $(git config user.name)" >| "$STAMP"
git add "$STAMP"
git commit -m "auto stamp update"
fihttps://stackoverflow.com/questions/40003498
复制相似问题