3

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

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

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

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

  1. 从开发分支创建一个新的 release-1.0 分支
  2. 进行更改（将环境设置为生产）（坏主意）
  3. 将更改提交到 release-1.0 分支
  4. 将 release-1.0 中的更改合并到 master 分支
  5. 将新版本标记为 1.0
  6. （这对我来说是模糊的）
  7. 进行更改（将环境设置为开发）（坏主意）
  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

这样做有意义吗？

基本上，每个主版本至少有两次提交。一个是设置生产变量，将这些变量合并到主分支，然后另一个提交将我们的变量更改回它们的开发设置并合并回开发分支。

4

1 回答 1

2

但是我在将发布分支合并到主分支，然后回到开发分支的部分有点困惑

这样做的原因可能是因为您的版本可能并不完美。您将提交与该版本相关的任何错误修复到release分支，并且新功能开发进入develop分支。然后，您将release分支合并到develop以将这些更改带入主开发流。

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

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

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

于 2012-10-10T03:07:47.487 回答