Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>However I'm a little confused at the part regarding merging the release branch into master, and then back into the develop branch</p> </blockquote> <p>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 <code>release</code> branch and new feature development goes into the <code>develop</code> branch. You then merge the <code>release</code> branch into <code>develop</code> to bring those changes into the main development stream.</p> <p>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:</p> <ul> <li><a href="https://stackoverflow.com/questions/1974886/how-to-version-control-config-files-pragmatically">How to version control config files pragmatically?</a></li> <li><a href="https://stackoverflow.com/questions/1396617/git-committing-machine-specific-configuration-files/1397180#1397180">Committing Machine Specific Configuration Files</a></li> <li><a href="https://stackoverflow.com/questions/419322/whats-the-best-practice-for-handling-system-specific-information-under-version?rq=1">What's the best practice for handling system-specific information under version control?</a></li> <li><a href="https://stackoverflow.com/questions/534119/semi-editable-files-eg-config-files-and-version-control-best-practices">Semi-editable Files (eg config files) and version control - best practices?</a></li> </ul> <p>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.</p> <p><a href="https://stackoverflow.com/a/419477/164966">VonC's answer</a> gives a pretty good perspective on this, specifically separating process of maintaining history and process of deploying your software.</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