Git生产/开发发布分支

9 浏览
0 Comments

Git生产/开发发布分支

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

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

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

我打算按照以下步骤进行：

  1. 从开发分支创建一个新的release-1.0分支
  2. 进行更改（将环境设置为PRODUCTION）（不好的主意）
  3. 将更改提交到release-1.0分支
  4. 将release-1.0的更改合并到主分支
  5. 将新版本标记为1.0
  6. （这是我困惑的地方）
  7. 进行更改（将环境设置为DEVELOPMENT）（不好的主意）
  8. 将更改提交到release-1.0分支
  9. 将release-1.0分支合并回开发分支

我使用一个shell脚本来自动执行这些更改，可能还有整个开发->发布->主分支的创建过程。我将调用这个脚本作为“#: update.sh production 1.0”

if !([ "$1" == "production" ] || [ "$1" == "development" ]); then
    echo "必须指定production或development作为第二个参数"
    exit;
fi
if [ ! -n "$2" ]; then
    echo "必须指定一个版本（例如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 "开始更改为$1..."
SRC="define('ENVIRONMENT', '.*');"
DST="define('ENVIRONMENT', '${var_env}');"
sed -i -e "s/[\s]*$SRC/$DST/g" index.php
echo "更新环境常量。"
echo "是否要继续并提交这些更改？（y|n）"
read WISH
if([ "$WISH" == "y" ]); then
    git checkout master
    git merge --no-ff release-$2
    git tag -a $2
else
    echo "好的。我放弃了。"
fi

按这种方式操作有意义吗？

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

0

1 答案

0 Comments

Git生产/开发发布分支出现的原因是为了将修复与发布相关的错误提交到release分支，而将新功能开发提交到develop分支。然后将release分支合并到develop分支，将这些更改带入主要的开发流程中。

为了更好地处理与特定机器相关的配置文件，一种解决方法是采用模板/替换/文件替身步骤在部署脚本中进行。这样可以消除人为因素，并几乎保证每次部署到特定环境时都会执行该步骤。

另一种解决方法是将系统特定的配置值存储在环境变量中，从而完全消除了对配置变量的版本控制的需求。

关于release分支的功能，它是develop分支的一个准备好的版本，其中包含对未完成的功能或错误进行调整，并允许在develop分支上进行持续开发。

感谢解释release分支。根据原始文章中的描述，'bump-version.sh'脚本的功能有些模糊，但现在很清楚，release分支确实是一个可发布的候选版本，包括错误修复等，但不包括新功能（因为这些功能正在发送到develop分支）。

0