Git Production / Development Release Branch

Question

Hello I'm thinking this should be a fairly simple question, but I'm not too familiar with managing git.

I'm using the extremely popular http://nvie.com/posts/a-successful-git-branching-model/ to give me a generic model for my git branching. However I'm a little confused at the part regarding merging the release branch into master, and then back into the develop branch.

I also like the Git best practice for config files etc but feel like that's not really the best way.

I'm thinking of doing the following:

create a new release-1.0 branch from the develop branch
make changes (set environment to PRODUCTION) (BAD IDEA)
commit changes to the release-1.0 branch
merge changes from release-1.0 into the master branch
tag the new version as 1.0
(This is where it gets fuzzy to me)
make changes (set environment to DEVELOPMENT) (BAD IDEA)
commit changes to the release-1.0 branch
merge the release-1.0 branch back into the develop branch

I use a shell script to automate the changes, and possibly the entire develop->release->master creation. I would call this script as "#: 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

Does it make sense to do it this way?

Basically we would have at least two commits for every master release. One to set the production variables, merge those variables to the master branch, and then one more commit changing our variables back to their development settings and merging back into the develop branch.

score 2 · Accepted Answer · edited May 23 '17 at 12:10

2

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

The reason that's done is because, presumably, your release won't be perfect. You will commit any bug fixes related specifically to that release to the release branch and new feature development goes into the develop branch. You then merge the release branch into develop to bring those changes into the main development stream.

What you are suggesting with having a second commit just for the sake of changing config settings and then reverting them is just asking for headaches and likely not worth doing. Similar questions about how to deal with machine specific config files have been asked here:

There are probably many other similar questions. The consensus of the ones above seems to be that putting correct versions of config files into the repository is a bad idea. Also, some kind of a template/replacement/file gnomes step in your deployment script is the way to go. It takes out the human element and virtually guarantees that the step will happen every single time you deploy to a particular environment.

VonC's answer gives a pretty good perspective on this, specifically separating process of maintaining history and process of deploying your software.

edited May 23 '17 at 12:10

Community

1
1

answered Oct 10 '12 at 03:07

Roman

19,581
6
68
84

I have read through many of those in the past, but none of them "felt" right. I have recently started toying with the idea of storing system-specific config values in environment variables. Entirely eliminating the need for version control of config variables. http://www.12factor.net/config. If I understand correctly, a `release` branch is basically a 99% ready version of the `develop` branch where we'd make tweaks to unfinished features or bugs and allow continued development on the `develop` branch? Is that correct? – Kyle Johnson Oct 10 '12 at 06:04
I agree with your last part of your answer ;) +1 – VonC Oct 10 '12 at 09:30
@KyleJohnson the config values are an entirely other issue, and should be kept in a separate referential. Git can help with content filter driver. See for instance http://stackoverflow.com/a/7630975/6309 – VonC Oct 10 '12 at 09:32
@KyleJohnson One thing to consider with environment variables for config settings is how long would it take you to stand up a particular environment from scratch if gremlins ate your old one. Presumably you'd have a script(s) that are able to recreate environment variables for every environment, and you are likely to want to version such script(s) so you are back to the same problem of how do you manage configurations. – Roman Oct 10 '12 at 15:30
@KyleJohnson 99% may be a little optimistic, but depends on the company. Think of the `release` branch as *"we will release everything that's here + bug fixes for whatever issues we find."* It's a way to let people commit new features as they get finished with destabilizing the release branch. – Roman Oct 10 '12 at 15:36
Thank you for explaining the `release` branch to me. It was a little vague in the original article what the 'bump-version.sh' script did, but now it's fairly clear that the `release` branch is exactly what it sounds like, it is a release candidate, bug-fixes and the like but no new features (because those are being sent to the `develop` branch). – Kyle Johnson Oct 10 '12 at 22:15

Git Production / Development Release Branch

1 Answers1