0

We are basically using the Git flow documented here: http://nvie.com/posts/a-successful-git-branching-model/. Now some questions have been raised by developers:

  1. From where do we release the code to production? The release/hotfix branch or the master?
  2. Need to rollback in release branch, if some features in the current release branch are no longer required.
  3. We are saying that the release branch will be locked down only to the lead, no code changes will be done here. This is deviated from the Git Flow, and I don't know why.

I have more questions:

  1. If there is no change in the release branch, why do we even need one? I am from the ClearCase world, and I always have this impression that a branch is not required if there is no change on it.
  2. Why Git is not using tag a lot. In ClearCase, we baseline/tag the development branch on every build, and we can use baseline/tag to identify a release, no need to create a branch for release. With baseline/tag, we can always take a previous baseline/tag to release, no need to rollback.
Jirong Hu
  • 1,957
  • 6
  • 31
  • 57

2 Answers2

1

Disclaimer: Answers given according to my understanding of git flow, so they may not be correct :)

1. From where do we release the code to production? The release/hotfix branch or the master?

From the article:

Therefore, each time when changes are merged back into master, this is a new production release by definition.

--> Production releases from master

 2. Need to rollback in release branch, if some features in the current
 release branch are no longer required.

You dont do features in the release branch, you do features in feature branches. In a release branch you do only minor changes/bugfixes or update the metadata prior to a release. If those changes are redundant its probably ok to rollback the branch, because they are minor changes anyway and probably not important.

Also from the article:

Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

3. If there is no change in the release branch, why do we even need one? I am from the ClearCase world, and I always have this impression that a branch is not required if there is no change on it.

If there are no changes you are right, the branch is probably redundant. But i think that inside your code you have the version number somewhere? This should be updated in the release branch.

From the article:

Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.).

Edit: 

4. Why Git is not using tag a lot. In ClearCase, we baseline/tag the development branch on every build, and we can use baseline/tag to identify a release, no need to create a branch for release. With baseline/tag, we can always take a previous baseline/tag to release, no need to rollback.

You dont have to use the newest commit of develop to start a release branch.

Sosian
  • 596
  • 11
  • 27
  • Thanks for the clerifications. Rollback is for at the final stage of release, people decide not to include that feature in that release. – Jirong Hu Dec 17 '15 at 20:06
  • Seem hard to build on git tag: http://stackoverflow.com/questions/10195900/jenkins-git-plugin-how-to-build-specific-tag – Jirong Hu Dec 17 '15 at 20:15
0

I will answer your first 2 questions According to this line in the arcticle

the release branch is merged into master (since every commit on master is a new release by definition, remember)

I would say you should release your code to production from master

As for rollbacks to remove a feature implemented previously I don't think its correct since you want the history of that code. you should just delete the deprecated code do a new commit.

Renato Herrera
  • 171
  • 1
  • 10