你好,我认为这应该是一个相当简单的问题,但我不太熟悉管理git。Git生产/开发发布分支
我使用非常流行的http://nvie.com/posts/a-successful-git-branching-model/为我的git分支提供了一个通用模型。不过我对于将版本分支合并到主版本的部分有点困惑,然后回到开发分支。我也喜欢Git best practice for config files etc,但觉得这不是最好的方法。
我想这样做的以下内容:
- 从develop分支创建一个新的版本,1.0分支
- 进行更改(组环境到生产)(坏主意)
- 提交更改到发布1.0分支
- 合并从发布1.0到主分支的变化
- 标签的新版本1.0
- (这是它得到模糊我)
- 进行更改(组环境发展)(坏主意)
- 提交修改到释放 - 1.0分支
- 合并将释放1.0分支回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
这样做有意义吗?
基本上我们每个主版本至少会有两次提交。一个用于设置生产变量,将这些变量合并到主分支,然后再提交一次将我们的变量返回到其开发设置并合并回开发分支。
我已经阅读了很多过去的文章,但没有一篇“感觉”是正确的。我最近开始玩弄将环境变量中特定于系统的配置值存储的想法。完全消除了对配置变量版本控制的需求。 http://www.12factor.net/config。如果我理解正确,'release'分支基本上是'develop'分支的99%准备版本,我们可以对未完成的特性或bug进行调整,并允许在'develop'分支上继续开发。那是对的吗? –
我同意你的答案的最后一部分;)+1 – VonC
@KyleJohnson配置值是一个完全的其他问题,应保存在一个单独的参考。 Git可以帮助使用内容过滤器驱动程序。例如http://stackoverflow.com/a/7630975/6309 – VonC