Git Production / Development Release Branch

Question

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

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

我也喜欢配置文件等的Git最佳实践，但感觉这不是最好的方式。

我正在考虑做以下事情：

1. 从develop分支创建一个新的release-1.0分支
2. 进行更改（将环境设置为PRODUCTION）（ BAD IDEA ）
3. 提交对release-1.0分支的更改
4. 合并从release-1.0到master分支的更改
5. 将新版本标记为1.0
6. （这是我模糊的地方）
7. 进行更改（将环境设置为开发）（ BAD IDEA ）
8. 提交对release-1.0分支的更改
9. 将release-1.0分支合并回develop开发分支

我使用shell脚本来自动化更改，并可能使用整个develop-> release-> master创建。 我将此脚本称为“＃：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的回答给出了很好的观点，特别是分离了维护历史和部署软件的过程。