0

We are trying to implement an automated workflow for deployment based on git. Currently, we have three environments: development/staging/production. The idea was to mark those environments as branches of the same name (except production=Master), we then have developed a small CLI which takes commands like this:

cli deploy -e production -t patch

This runs a bunch of internal tasks and, as a final step, merges the local branch into the correct environment branch (in this case Master), then bumps the version in package.json according to SemVer specification (in this case, a patch level version will increment the major.minor.patch part) and tags the commit appropriately.

This works very well: we always know what is deployed in which environment, we can rollback easily and we have taken certain steps out of individual developers mistakes.

However, this also results in a less than pretty git log. First off, branch Master is comprised only of merge commits (Merge branch 'hotfix', Merge branch release-2.0.0, etc.), since we decided to keep the branch history intact. Is this the way it is supposed to look like in the Git Flow Model?

Also, we bump the version after the merge, so really Master branch looks always like: Merge branch 'hotfix', Bumping version to 2.3.1.

This looks quite ugly and, especially as the project grows, starts becoming more confusing. I'm sure there must be a cleaner way to do this, but I can't figure out what we could adjust.

Sunyatasattva
  • 5,619
  • 3
  • 27
  • 37
  • BTW, you don't need to use the master branch name and can rename it to production, see something like http://stackoverflow.com/questions/8762601/how-do-i-rename-my-git-master-branch-to-release – David Neiss Aug 19 '15 at 19:23
  • Ah well, that's not really the problem. I don't mind the branch being named Master. – Sunyatasattva Aug 20 '15 at 15:59

0 Answers0