CODEWITHSUNDEEP
gitbranchreleaseconfigproduction
Kyle Johnson
Kyle Johnson

Reputation: 659

Git Production / Development Release Branch

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:

  1. create a new release-1.0 branch from the develop branch
  2. make changes (set environment to PRODUCTION) (BAD IDEA)
  3. commit changes to the release-1.0 branch
  4. merge changes from release-1.0 into the master branch
  5. tag the new version as 1.0
  6. (This is where it gets fuzzy to me)
  7. make changes (set environment to DEVELOPMENT) (BAD IDEA)
  8. commit changes to the release-1.0 branch
  9. 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.

Upvotes: 3

Views: 2781

Answers (1)

Roman
Roman

Reputation: 20246

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.

Upvotes: 2

Related Questions