"J. R. Westmoreland" <jr@xxxxxxx> writes:
> I have a number of repos that were converted from svn to git. After
> the conversion the branches that contained each release were named
> something like “branches/version_<version-number>”. We want to
> modify the repo so the branches are named something like
> “release/<version-number>”.
>
> I currently do a command sequence like this:
> git checkout <existing-branch>
> git branch -m <existing-branch> <new-branch>
> git push origin :<old-branch>
> git push origin <new-branch>
> Then I do a:
> git checkout master
> git branch -D <new-branch>
> to cleanup my local area.
>
> Note: These branches are only kept for historical purposes and not
> modified except occasionally the latest release may have an update so
> fix a bug.
>
> Finally, as we move forward, what is the accepted best practice for doing a release?
A few comments:
1. You can rename a branch without checking it out, can't you?
$ git branch -m version_1.0 v1.0
$ git branch -m version_1.1 v1.1
...
2. If you want to only correct what is shown at origin to the other
people, then you do not have to update your local repository.
$ git push origin version_1.0 v1.0
$ git push origin version_1.1 v1.1
...
3. If these old ones are meant to be immutable, then storing them as
tags instead of leaving them as branches might make more sense,
i.e.
$ git push origin version_1.0 tags/v1.0
$ git push origin version_1.1 tags/v1.1
...
If you are still actively maintaining an older release, you would
still want to have release points marked on the maintenance
branch, so 2. and 3. can be combined. Branch v1.0 may be used to
backport fixes to produce v1.0.x releases, each of which would be
tagged individually, perhaps like this:
$ git checkout version_1.0
: rename it to maint-1.0 to clarify this is for 1.0.x series
: maintenance
$ git branch -m maint-1.0
: tag the released version, with GPG signature
$ git tag -s v1.0 maint-1.0
: push the whole thing out
$ git push origin maint-1.0 v1.0
: when it is time to do more on the older maintenance track
$ git checkout maint-1.0
: hack hack hack to prepare maintenance release
$ git commit
: sign the release tag
$ git tag -s v1.0.1
: push the whole thing out
$ git push origin maint-1.0 v1.0.1
3. is what I would be using if I were you.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html