OT: You can check out the following for some standard git workflows. http://nvie.com/posts/a-successful-git-branching-model/ https://www.atlassian.com/git/workflows
My teams uses a combination of gitflow and pull requests. We maintain a central repo with gitflow standards with one modification. We have a production branch and uses master as develop. We decided that master is the default branch it was easier for new developers to get started, and there are few incidents of new developers pushing 'dev' code into my production ready release branches. Our team forks into their own repositories and has a free for all in terms of team and group collaboration and naming standards. The submit pull requests to the proper branches on the central repo. Normally we restrict access to the central repo to release managers so we don't have to worry about people using it as a personal playground. Some times we'll setup multiple central repos for staging and production with different access control for each stage of the release process. Depends on what kind of sign-off and QA workflows our clients dictate. On Wed, Mar 12, 2014 at 10:27 AM, <christopher_dearb...@dell.com> wrote: > Disclaimer: I am not a github expert. > > > > Regarding branch lifecycle: > > 1. Work on the release being actively developed continues in a branch > > 2. When that release is shipped, another branch is made so that > active development on the next release can continue in one branch, and > critical fixes can be made in the shipped branch only if needed > > > > It sounds like the recommendation for best practice is to convert the > shipped branch to a tag once that branch is no longer supported? Is there > a safe way to do this without risking losing the branch? > > > > If a branch has 1 change in it that is not included in any other branch, > then it can't be converted to a tag can it? > > > > > > Thanks, > > > > Chris > > Dell > > -----Original Message----- > From: crowbar-bounces On Behalf Of Sascha Peilicke > Sent: Wednesday, March 12, 2014 10:07 AM > To: crowbar > Subject: Re: [Crowbar] Removing branches fully merged into "master". > > On Wednesday 12 March 2014 13:59:57 Adam Spiers wrote: > > [BTW no need to send to both crowbar@dell.com and > > crow...@lists.us.dell.com] Sascha Peilicke (sasc...@mailbox.org) wrote: > > > On the other hand, seasoned developers with an eye for beauty are > > > consistently annoyed by the continued over-use of Github. > > > > I'd call it abuse or misuse of git rather than over-use of github, but > > essentially I agree. > > > > > People use the "crowbar" Github > > > organization for their private feature-fiddling while they should do > > > that in their own fork. Whether to keep stable-release branches or > > > use tags instead is a matter of taste, I believe. > > > > Not quite, IMHO - unmaintained stable releases should be tagged, and > > maintained stable releases should be branched. At risk of stating the > > obvious, this is because git tags are intended for stationary > > snapshots, whereas branches are intended for tracking moving targets. > > Very well written and I agree. It all depends how "moving target" is > defined. > So far I don't think we properly phase out "old branches". People just > stop to push code there at some point. In other words, we should think > about a proper release life-cycle. > > Dunno what that means for Dell's pile of branches, but the SUSE guys more > or less informally fix at most 3 branches. That is the current dev branch > > (stoney) and the two releases in maintenance (pebbles aka SUSE Cloud 2.0 > and roxy for SUSE Cloud 3). > > > > But the following examples are really a miss-use: > > > remotes/crowbar/release/hadoop-2.1/master > > > remotes/crowbar/release/hadoop-2.2/master > > > remotes/crowbar/release/hadoop-2.3/master > > > remotes/crowbar/release/hadoop-2.4/master > > > > > > It should be one "hadoop" branches with tags 2.1, 2.2, 2.3 and 2.4. > > > > That depends on whether there is an intention to maintain 2.1 > > independently of 2.2 etc. > > Yes, closely related to the life-cycle discussion above. > > > > remotes/crowbar/release/mesa-1.6.1/master > > > remotes/crowbar/release/mesa-1.6/master > > > remotes/crowbar/release/mesa-1.7/master > > > > > > Same here. > > > > I'm not so sure - IIRC at least two of these are considered > > independent releases. > > Ok, in that case I don't know enough about Dell guy's commitment to the > mesa branches. > > > > remotes/crowbar/release/mesa-1.6.1/openstack-build/master > > > > > > WTF? Away with thee! > > > > Yeah there is a big WTF factor with that. It stems from the abuse of > > git branches to track not only releases but also products, or builds, > > or something else depending on your preferred terminology. > > > > > I guess that's where the most cleanup potential lies. > > > > I'd say removing ancient feature / topic branches is the lowest > > hanging fruit. > > And the least controversial. > -- > Viele Grüße, > Sascha Peilicke > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ >
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
