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? I don't think there is a "right" model, but at least _one_ model is what the kernel uses: - the actual "release" is just tagged - any release development (ie "maintenance") is literally done in a totally separate repository, both from a development standpoint _and_ an actual release management standpoint. This may sound strange, but it actually has what I consider to be huge advantages: - it fits very well in the "distributed" mental model - it makes the separation of "maintenance" and "development" very very clear. It's clear at all levels that the two are not the same thing, don't have the same goals, and often not done by even the same groups, or even by same management. I think the second point is actually important. At the same time, the distributed model of git means that if you want to mix the two trees, you easily can: you just fetch from the two independent release trees into the same repository. So the fact that they are maintained completely independently doesn't mean that they can't be joined, it just means that there's a clear separation at all levels. Also note how _different_ releases may well end up having _separate_ repositories. So it's not that there is "one repository for development, and one repository for maintenance". It's literally "one repository for _each_ release maintenance". Now, I think this kind of "separate repository for release maintenance trees" is actually a great model, and I think it can make perfect sense in various commercial/proprietary settings too (ie I know from experience that you tend to often have separate groups and very different rules for maintenance, so having the separate repository really does make sense). But at the same time, for a smaller project, it obviously does NOT make sense. Git itself, for example, just has a "maint" branch, and does everything with the same maintainer, and in the same repository. Within something like git, that makes sense, because there just isn't a separate "stable tree maintainer", and trying to enforce that kind of thing would just be insane anyway within the setting of git. So in some settings, you might just have a branch for each stable release, or as in the case of git, just a single branch for "maintenance", just because nobody is going to maintain older releases really at all (that might change with time, of course, but I think it's a pretty common pattern for smaller projects). In short: I don't think there is "one correct way" to do these things. Linus - 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