Hi,

On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
quoted text
> Hi,
>
> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 12 Dec 2006, Sean Kelley wrote:
> >
> > > I was wondering if anyone could share ideas on how best to use GIT to
> > > handle releases for those working with a remote GIT repository?  Do you
> > > create a branch and push it to the remote?  Thus you have a new branch
> > > referencing the particular release?
> >
> > Why not just tag the release, and push the tag?
>
> I am doing both in my web SDK project.
>
> I currently have two branches, master and maint/v1. Over time, if
> necessary, I'll open new branches named maint/v2, maint/v3 etc.
>
> New development happens on master, bugfixes go to maint/v1 and get
> merged into master. If I do bugfix releases (2.0.x), I tag the tip of
> the maint/v1 branch.


That seems to match my use case.  So if I follow your description:

  git checkout -b maint/v0.1
  git pull . <remote project repo>
  git push origin maint/v0.1:maint/v0.1

Now the initial branch release is on the remote repo.  So that my team
can start hacking on the release branch.  When we are ready, we need
to create a release tag.

   git tag -a -m "Release 0.1.0" rel-v0.1.0

How do I push that tag that I created to the maint/v0.1 branch on the
remote repository?

Thanks,

Sean


quoted text
>
> I need a full branch, because I need the ability to do bugfixes for the
> already-released version.
>
> Matthias
>
>


-- 
Sean Kelley
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html