Note that there are some explanatory texts on larger screens.

plurals
  1. POGit Production / Development Release Branch
    text
    copied!<p>Hello I'm thinking this should be a fairly simple question, but I'm not too familiar with managing git.</p> <p>I'm using the extremely popular <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">http://nvie.com/posts/a-successful-git-branching-model/</a> to give me a generic model for my git branching. However I'm a little confused at the part regarding merging the <em>release</em> branch into <em>master</em>, and then back into the <em>develop</em> branch.</p> <p>I also like the <a href="https://stackoverflow.com/questions/9342886/git-best-practice-for-config-files-etc">Git best practice for config files etc</a> but feel like that's not really the best way.</p> <p>I'm thinking of doing the following: </p> <ol> <li>create a new release-1.0 branch from the develop branch</li> <li>make changes (set environment to PRODUCTION) (<strong><em>BAD IDEA</em></strong>)</li> <li>commit changes to the release-1.0 branch</li> <li>merge changes from release-1.0 into the master branch</li> <li>tag the new version as 1.0</li> <li><em>(This is where it gets fuzzy to me)</em></li> <li>make changes (set environment to DEVELOPMENT) (<strong><em>BAD IDEA</em></strong>)</li> <li>commit changes to the release-1.0 branch</li> <li>merge the release-1.0 branch back into the develop branch</li> </ol> <p>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"</p> <pre><code>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 </code></pre> <p>Does it make sense to do it this way?</p> <p>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload