Hi, On 12/13/06, Matthias Kestenholz <lists@xxxxxxxxxxx> wrote:
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
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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html