1

With one eternal branch, let's call it master for the sake of the question, how can one implement a successful release process?

A branch is created from the master branch, called release/v1.1.0. In the meantime, development continues on the master branch. Hotfix commits are done directly on the release/v1.1.0 branch. After release package is created and deployed to production, release/v1.1.0 is merged with master and deleted.

Problem: If an issue is found on production, is it possible to create a branch that matches state on production? Or is the release/v1.1.0 branch needed?

MichaelAttard
  • 1,898
  • 2
  • 17
  • 26
  • Why would you merge the release branch with master (and delete it afterwards)? – melpomene Apr 30 '17 at 19:12
  • @melpomene I'm assuming because it would contain fixes to release issues and issues found during the release process. – thebjorn Apr 30 '17 at 19:14
  • If you tag it you shouldn't have any problems getting back to it: http://stackoverflow.com/questions/10940981/git-how-to-create-a-new-branch-from-a-tag – thebjorn Apr 30 '17 at 19:16
  • @thebjorn Correct. – MichaelAttard Apr 30 '17 at 19:17
  • What would you tag? Once merged would the tag only contain changes on the release branch (while avoiding changes done on the master branch) ? – MichaelAttard Apr 30 '17 at 19:17
  • In that case you can always get it back because it's one of the ancestors of the merge commit. You'd tag the state of the release branch immediately before the merge and/or delete. – melpomene Apr 30 '17 at 19:18
  • I would tag what you're putting in production (since that's what you want to get back to). It's not a bad idea to keep the release branch around either if you ever have a need to do any hot-fixes. – thebjorn Apr 30 '17 at 19:19
  • @melpomene Does git allow tagging git hashes? If that's the case then that would actually work – MichaelAttard Apr 30 '17 at 19:19
  • That's the question, is it possible to restore a branch from a tag? – MichaelAttard Apr 30 '17 at 19:20
  • 1
    git allows tagging hashes (http://stackoverflow.com/questions/4404172/how-to-tag-an-older-commit-in-git). You can't restore a branch from a tag, but you can create a new branch from a tag (see link in my comment above). – thebjorn Apr 30 '17 at 19:22
  • 1
    You can `git tag your-tag-name-here 2378eabcff3` to tag an arbitrary commit, and you can `git checkout your-tag-name-here` afterwards. – melpomene Apr 30 '17 at 19:23
  • Ok I think that would qualify as an answer – MichaelAttard Apr 30 '17 at 19:24

1 Answers1

4

I would tag the released commit. 

git tag release/v1.1.0 COMMIT

Where COMMIT identifies the released commit (its hash, for example)

Then, if you have to fix something on production, you can create a branch from this tag. You can call it release/v.1.1.X

On this branch you can create the release/v.1.1.1, release/v.1.1.2, etc versions.

To create a branch from a tag you can do

git checkout -b release/v.1.1.X release/v.1.1.0

This creates a release/v.1.1.X branch starting from the release/v.1.1.0 tag

If you simply want to see which code has the release/v.1.1.0 version, you can simply do a checkout of that commit:

git checkout release/v.1.1.0

Please note, that tags are not automatically pushed to remote. So can push a tag with

git push origin release/v.1.1.0

(supposing your remote is 'origin'), or you can push all your local tags with

git push --follow-tags
Manuel Schmidt
  • 2,178
  • 2
  • 15
  • 19