Git 生产/开发发布分支

Question

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

我正在使用极受欢迎的http://nvie.com/posts/a-successful-git-branching-model/ 为我的 git 分支提供一个通用模型。但是，关于将 release 分支合并到 master，然后再回到 develop 分支的部分，我有点困惑。

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

我正在考虑做以下事情：

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 "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 以将这些更改带入主开发流。

您建议进行第二次提交只是为了更改配置设置然后恢复它们只是让人头疼并且可能不值得这样做。有关如何处理特定于机器的配置文件的类似问题已在此处提出：

• How to version control config files pragmatically?
• Committing Machine Specific Configuration Files
• What's the best practice for handling system-specific information under version control?
• Semi-editable Files (eg config files) and version control - best practices?

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

VonC's answer 对此给出了很好的看法，特别是将维护历史记录的过程和部署软件的过程分开。