CODEWITHSUNDEEP
gitconfigconfiguration-filesconfigure
Maroshii
Maroshii

Reputation: 4017

Git branching model workflow - develop/master branches

The git branching model has a workflow in which we have two branches with an infinite lifetime : develop and master where master reflects a production ready state and develop a state with the latest delivered development changes.

To move from develop into master we go through an intermediate state, a release branch which supports preparations of a new production release. After these preparations (a shell script or maybe manual changes) we merge the release branch into master, tag it and push it to production.

At this point production only changes are made since, for example, external services have different URL in production than they do in a staging environment.

Now master is ahead of develop and always will be unless I merge it back into develop.

If I (a) do that all my production only changes made in the release branch will be merge back into develop

If I (b) don't do that my master will always be ahead and behind develop and in the case of a hotfix that branches off master i will end up merging all back into develop anyway after the fix.

What is the best way to work with this model while making sure I keep production only changes away from my develop branch?

Upvotes: 1

Views: 259

Answers (1)

Howie Ross
Howie Ross

Reputation: 76

This is really more of a configuration management question than a git question. This issue is not unique to git and is an issue with all version control systems. The best practice is to eliminate all production only changes or at least reduce them to the bare minimum.

This can be done in a number of ways:

  • Put configuration values in the database. This works until you get annoyed with having to make db changes to change a simple config

  • Put configuration in a file and use if statements based on a single variable that changes in production. For example:

    if ( production ) value = key
    else value = otherkey

    this isn't great either because now you essentially have untested code.

  • Put config in environment variables. This works pretty well, but you better be sure your deploy process instantiates and populates them.

  • But if you want to get real state of the art, put your config in it's own repository and use automation tools like puppet and chef

Upvotes: 1

Related Questions