On 08/10/10 15:02, Bradley Wagner wrote:
I realize there are a lot of different Git workflows but I'm wondering how others in this community do it. We're using our "master" branch from our central repo (Beanstalk) as a dev branch and we have stable branches for various release versions of our software. We've not made as heavy use of feature branches yet as we should have. Once we do start using them more regularly, what kind of stuff is ever committed directly to "master" or is master typically the place where things are merged into from other stable/features branches? Is "master" really even unstable at that point?
If your repo is accessible to the public then I think it makes sense to have master be stable. Because that's what people will see by default if they clone your repo, and you want to make a good first impression.
If it's a private repo that only insiders are allowed to see, then it doesn't matter as much.
Our team uses unstable master, which anyone on the team can push to. If someone pushes to it then a build and tests automatically run, and if they succeed then that commit gets automatically pushed to the stable branch. We let anyone create shared branches on the server if they want to collaborate on a feature. We make a tag for each release, but we don't make a maintenance branch until we actually need it.
-- David Ripton dripton@xxxxxxxxxx -- 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