Question

您好我认为这应该是一个相当简单的问题，但我对管理git不太熟悉。

我正在使用非常受欢迎的http://nvie.com/posts/a-successful-git-branching-model/来为我的git分支提供一个通用模型。但是我对将发布分支合并到 master ，然后再回到 develop 分支这一部分感到困惑。

我也喜欢Git best practice for config files etc，但感觉这不是最好的方式。

我正在考虑做以下事情：

从开发分支
进行更改（将环境设置为PRODUCTION）（ BAD IDEA ）
提交对release-1.0分支的更改
将版本1.0中的更改合并到主分支
将新版本标记为1.0
（这是我模糊的地方）
进行更改（将环境设置为开发）（ BAD IDEA ）
提交对release-1.0分支的更改
将release-1.0分支合并回develop分支

我使用shell脚本来自动化更改，并可能使用整个develop-＆gt; release-＆gt;主创建。我将此脚本称为“＃：update.sh production 1.0”

if !([ "$1" == "production" ] || [ "$1" == "development" ]); then
    echo "Must specify production or development as the second argument"
    exit;
fi

if [ ! -n "$2" ]; then
    echo "Must specify a version (e.g., 1.2, 1.2.1)."
    exit;
fi

if ([ "$1" == "production" ]); then
    var_env="production";
    git checkout -b release-$2 develop
fi

if ([ "$1" == "development" ]); then
    var_env="development";
fi

echo "Starting change to $1..."

SRC="define('ENVIRONMENT', '.*');"
DST="define('ENVIRONMENT', '${var_env}');"
sed -i -e "s/[\s]*$SRC/$DST/g" index.php
echo "Updated environment constant."

echo "Do you wish to continue and commit these changes? (y|n)"

read WISH

if([ "$WISH" == "y" ]); then
    git checkout master
    git merge --no-ff release-$2
    git tag -a $2
else
    echo "Okay. I give up."
fi

这样做是否有意义？

基本上我们每个主版本都会有至少两次提交。一个用于设置生产变量，将这些变量合并到主分支，然后再一个提交将变量更改回其开发设置并合并回开发分支。

Answer 1

然而，我对有关合并的部分感到有些困惑将分支发布到master，然后再回到develop分支

之所以这样做是因为，据推测，你的发布并不完美。您将向release分支提交与该版本相关的任何错误修复，并且新功能开发将进入develop分支。然后，将release分支合并到develop，以将这些更改纳入主开发流。

你建议第二次提交只是为了更改配置设置然后还原它们只是要求头痛并且可能不值得做。关于如何处理机器特定配置文件的类似问题已在此处提出：

可能还有很多其他类似的问题。上述内容的共识似乎是将正确版本的配置文件放入存储库是一个坏主意。此外，部署脚本中的某种模板/替换/文件gnomes步骤是可行的方法。它取消了人为因素，并且几乎可以保证每次部署到特定环境时都会发生这一步骤。

VonC's answer对此提供了很好的观点，特别是分离了维护历史记录和部署软件过程的过程。

Git Production / Development Release Branch

1 个答案: