A few of us were discussing possible changes to our git strategy today and figure we'd ask around for additional feedback and ideas.
Currently our 'master' branch is viewed as pristine, we never touch it until we have a release, at which point we merge our changes from our development head 'next' or other special topic branches into it. This is how the upstream git community manages their repository, though they are the only other ones using this strategy that I know of. Their approach seems to be different than ours though as their master and next branches primarily consist of merge commits from others https://github.com/git/git/commits/ https://github.com/git/git/commits/next Many other git based projects use master as the primary development head, tagging various releases as they are ready, and branching only when a separate development track is necessary. For example, the ruby upstream community develops against master (technically against the 'trunk' head in a svn repo which their git 'master' is a mirror of) with branches for 1.8.7 and 1.9.1 development. One of the benefits of doing it this way is that when developers checkout the master branch (as would happen by default when one does a git clone), they automatically have the latest development HEAD and do not have to worry about or remember to switch branches before being able to start development (though in practice its a good idea to create a new local branch for any new changes). Several of us wanted to change our git strategy to be more aligned with this approach that many other projects make use of as well, but figure it'd be best put up for a vote, so that any others with opinions regarding this could have a say. If you're interested, please response with a (+/-)1 and any thoughts. Thanks alot, -Mo _______________________________________________ deltacloud-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/deltacloud-devel
