git-flow seems a bit overkill to me, for the reasons stated here: http://scottchacon.com/2011/08/31/github-flow.html
Although I have to admit I never tried it in anger. Thanks for the atlassian.com link - really nice site! Darrel O'Pry (darrel.o...@gmail.com) wrote: > 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/ _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
