Git 生产/开发发布分支

Question

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

我使用的是非常流行的 http://nvie.com/posts/a-successful-git-branching-model/为我的 git 分支提供一个通用模型。然而，关于将 release 分支 merge 到 master，然后再 merge 回 develop 分支，我有点困惑。

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

我正在考虑执行以下操作:

1. 从 develop 分支创建一个新的 release-1.0 分支
2. 进行更改(将环境设置为生产环境)(BAD IDEA)
3. 将更改提交到 release-1.0 分支
4. 将 release-1.0 的更改 merge 到 master 分支
5. 将新版本标记为 1.0
6. (这是让我感到模糊的地方)
7. 进行更改(将环境设置为 DEVELOPMENT)(BAD IDEA)
8. 将更改提交到 release-1.0 分支
9. 将 release-1.0 分支 merge 回 develop 分支

我使用 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

这样做有意义吗？

基本上我们会为每个主版本至少进行两次提交。一个用于设置生产变量，将这些变量 merge 到 master 分支，然后另一个提交将我们的变量更改回它们的开发设置并 merge 回开发分支。

Answer 1

However I'm a little confused at the part regarding merging the release branch into master, and then back into the develop branch

之所以这样做，大概是因为您的发布并不完美。您将提交与该版本具体相关的任何错误修复到 release 分支，新功能开发进入 develop 分支。然后将 release 分支 merge 到 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?

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

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