Please add support for starting a release from a tag

[fields]

I'm not sure if this is the right place for this - please let me know if not. This issue has manifested using Git Tower, and they've said they just pass the commands through to the AVH fork for git-flow. What I'm describing below used to work, and I don't know if it's because it's not supported in the AVH fork and they just switched to that, or something changed and it became no longer supported.

We use the develop branch as the deployment source for our staging environment, and set a tag when deployments are pushed to the staging server. We've been using those tags as the starting point for each release which is then deployed to the production environment. Tagging the deployment to staging and basing the release on that gives us assurance that the code in the release is exactly the same as the code we've tested in the staging environment.

As it seems to exist now in this version, a branch is required to start a release, which means if we want to keep using this workflow we'll have to create a new branch for every staging release and keep them around indefinitely, which would be messy. Just using the develop branch as the source for releases is problematic - people sometimes push changes back to the develop branch after the staging deployment but before the release is created.

Please consider adding (or adding back) the ability to start a release from a tag.

Thank you!

[fields]

Just checking in on this - does this request make sense?

[petervanderdoes]

I'll dig into it in the next couple of days.

[fields]

Thanks - any update on this?

[petervanderdoes]

What you are describing sounds like releasing multiple releases at the same time, which is not what the gitflow workflow is designed for.

If you need to support multiple releases, like a 1.x and a 2.x version you would have to start using the support branches.

To clarify why I think it starting a release from a tag in the develop branch won't work:

• You develop on the develop branch.
• You start a release, a release branch is created. This would be the branch that is pushed to staging.
• You can continue to develop on both develop and release branch(staging)
• When ready for production, the release is finished. The release is merged into master (production), master is tagged, master is merged into develop.

When you finish a release, the release is tagged in the master branch which is then back merged into the develop branch. In the original nvie version this was not the case, which let to problems with git describe, which is why it is done the way it is now.

[fields]

I'm not talking about multiple simultaneous releases, but supporting deployments to staging from a dynamic branch (the release branch) is more difficult to manage than a consistent rule that the head of the develop branch is always deployed to staging. I don't see it as a problem to support the choice of starting the release directly from develop or optionally from a tag.

[petervanderdoes]

I'm trying to get a clear picture of your workflow.

• You set a tag (TagA) on the develop branch for version 1.0.0
• You create a Release branch based on TagA
• you push to staging server from TagA.

On which branch do you fix bugs found on the staging server? Are people developing the next version, 2.0.0, on development simultaneously?

According to the original workflow, bugfixes for a release should be done on the release branch. You could tag on the release branch and use those tags to push to staging.

[fields]

Our basic workflow looks like this:

1. Create feature branch from develop. Test locally. Complete feature branch & merge back to develop.
2. Deploy develop to staging, and test there. If issues are found, either create a new feature branch to fix and repeat step 1, or if very minor then just fix directly on develop and deploy to staging again. Every deploy to staging is automatically tagged (by capistrano).
3. When things pass tests on staging, create a release (from the tag that was pushed to staging), do any release-specific stuff (version numbers, docs), then finish release & merge to master.
4. Deploy master to production (deployments to production are also automatically tagged).

[fields]

I'm happy to discuss the possibility that our workflow may not be the best one, but it doesn't make intuitive sense to me to create a release before testing on staging is done - that seems to lead to the case where if issues are found on staging you're doing development directly in the release branch to fix them. I'd rather roll back into development / feature branches if that happens. (Also we don't tag version numbers until we're ready to do a release.)

[fields]

Any further thoughts?

[petervanderdoes]

Oh I probably will do this but maybe with an configuration to be set. something like gitflow.release.allow.from.tag or something.

Would that work for you?

[fields]

That sounds fine to me, but I use this primarily through Tower.app, so I've asked them to weigh in as well.

[aiman-alsari]

Hi, I've just bumped into the same issue - git flow release start <release_name> <base> always starts the release from HEAD of <base>. In some cases it would be more suitable to provide a tag or a commit hash to release from.

Interestingly, this only seems to be an issue with this fork (which I'm only using because it comes with Ubuntu). The original nvie repo, and all documentation around it, implies that a commit hash/tag is used for <base> not a branch name.

[petervanderdoes]

Been short on time for a while, I hope to get to this in a few days.

[dmitryd]

@aiman-alsari

Interestingly, this only seems to be an issue with this fork (which I'm only using because it comes with Ubuntu). The original nvie repo, and all documentation around it, implies that a commit hash/tag is used for not a branch name.

True. I use nvie's version locally and I have Peter's version at work. Local version works, at work it does not.

[dmitryd]

Oh, and it is really helpful to make a release from a tag or commit id. We generally need to make it from the commit id because this is what we have on stage for the customer to test. So I have to keep a copy of the git-flow where it works.

[stefancarlton]

I've just ran into this problem to. I resolved it by creating a temporary local branch and then releasing from there, which whilst messy, works. For future me...

git branch temp_branch <SHA1>
git flow release start <release_name> temp_branch
git branch -d temp_branch

Edit Note... doing this merges the change back down to temp_branch, which you then have to manually merge into master and then re-tag. Aka, it's a PITA.

[jbotuckBH]

I just ran into this problem as well. My workaround was to create the release branch with the right naming conventions manually. git flow release finish RELEASE worked as expected afterwards

[brunovieira97]

Been short on time for a while, I hope to get to this in a few days.

Any news or development on this?

Our development process here has a continuity such as a release might have it's last commit tagged on develop some time before the release branch is created.

Using branch names instead of tags or hashes (the second one is the best IMHO) makes it easy to include commits from the next planned release inside the current one.

[dmitryd]

Since I was waiting for too long on this to be implemented, I decided to do it without git flow. It is easy to do it with plain git. Not need for a wrapper like git flow anymore.