First major release from git

I have just released V1.0.0 of a product fr开发者_如何学Goom git and I am wondering what the recommended advice is from now.

Do I create a v1.0.0 branch or is a v1.0.0 annotated tag, a better alternative?

A tag seems the right approach to me but I am unsure of the workflow of branching and merging from the tag.

The catch phrase has been expressed on StackOverflow elsewhere:

Branches are for work, tags are for releases.

Your mainline branch (usually master) should be continuos forward development for the next release. Each time a release is made use a tag (annotated at a minimum) to mark the event.

If you need to make a maintenance release for a released version while you are working on the next version, you can checkout the tag, and create the branch from that point.

git checkout -b <tag>-maintenance <tag>

This will create a new branch for your maintenance work. You will follow the same process on the maintenance branch by tagging the release on the maintenance branch when you are finished with the maintenance release.

If there is no other forward development on the release (master) branch, you can just add the maintenance work onto that branch, tag again, and move on.

With git you're free to create branch at any time! I would do the following:

1. Create tag 'v1.0.0'
2. When I need to add some fix to version 1.0.0, I would create a branch 'v1.0.0-maintenance' based on my tag.
3. If you want to take the fix to current version, merge 'v1.0.0-maintenance' to 'master' or use cherry-pick

Depends, but I assume you will want to continue to fix v.1.0.0 quite soon while working on the next version as well.

I'd create a branch straight away. It's highly unlikely that you won't need it (only case would be that you never need to create v1.0.1).

You can of course also tag it (never hurts) and then later create the branch based on that tag. You can create a branch from a tag simply with

git checkout -b 1.0.0 v1.0.0

An annotated tag is probably the first thing you should do.

From there, you have several choices for your workflow: here are two of the most common options.

You can move on in a "forward-only" style of development, where the 1.0 series is never supported anymore (1); you can do "support-only" on 1.0 series and all new features get added to the 2.0 series (or substitute 1.0.1 and 1.1, leaving 2.0 for a full rewrite -- the version numbers aren't that important) (2).

Scenario 2 is definitely the more "professional" option, but if it's a smaller project with a narrow scope, Scenario 1 is okay.

In Scenario 1, you can either do all your work in the master branch, or do feature branches, merging into master when ready. When you have a new release, just tag it as 1.1 or 1.0.1 or whatever.

In Scenario 2, you can use your master branch to reflect the newest release, a "support" branch to reflect your support release, a "staging" branch to stage and test new features that will eventually get merged into master, and you can use feature branches for development of new features or bug fixes. And as you deploy bug fixes, you'll merge the support branch back into master. When you release either a new version or a support version, just use an annotated tag again.

Personally, I'm usually in favor of the master-staging-support branch with tags, rather than having a branch for each versioned release; but that's the great thing about git -- you can do it however you see fit! So of course, the two options I've presented are by no means the only options you have for your development workflow.