Git生产/开发发布分支

Question

Git生产/开发发布分支

3

你好，我认为这个问题应该很简单，但是我不太熟悉Git的管理。

我正在使用极其流行的http://nvie.com/posts/a-successful-git-branching-model/，它为我的Git分支提供了通用模板。然而，我有点困惑于关于将release分支合并到master中，然后再合并回develop分支的部分。

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

我考虑采取以下步骤：

从develop分支创建一个新的release-1.0分支
进行更改（将环境设置为PRODUCTION）(坏主意)
提交更改到release-1.0分支
将修改从release-1.0合并到master分支
标记新版本为1.0
(这就是我感到困惑的地方)
进行更改（将环境设置为DEVELOPMENT）(坏主意)
提交更改到release-1.0分支
将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

这种方式有意义吗？

基本上，每次主要发布都需要至少两个提交。第一个是为了设置生产变量，将这些变量合并到主分支中，然后再进行一次提交，将变量改回开发环境的设置，并将其合并回开发分支。

- Kyle Johnson

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Roman · Accepted Answer

然而，我对将发布分支合并到主分支，然后再合并回开发分支的部分有些困惑。这样做的原因是因为，你的发布很可能不完美。您将针对该发布的任何与错误修复提交到“release”分支，新功能开发则进入“develop”分支。然后，您将“release”分支合并到“develop”以将这些更改引入主要开发流程中。

您所建议的仅为更改配置设置并撤消它们而进行第二次提交，只会带来麻烦，很可能不值得做。在这里还提出了有关如何处理特定于机器的配置文件的类似问题：

可能还有许多类似的问题。以上问题的共识似乎是将正确版本的配置文件放入存储库是不好的。此外，一些模板/替换/文件精灵步骤在部署脚本中是可行的方法。它消除了人为因素，并几乎保证每次部署到特定环境时都会发生这一步骤。

VonC的回答提供了一个相当好的视角，特别是将维护历史记录的过程与部署软件的过程分开。