[Bioperl-l] git branches, tags, 'topic/bug_####'
    Jay Hannah 
    jay at jays.net
       
    Thu May 13 14:38:20 UTC 2010
    
    
  
So, like this?
Flow diagram:
   http://biodoc.ist.unomaha.edu/~jhannah/tmp/branches.png
master         
   (git and github default) Trivial changes committed directly here. 
topic/bug_####
   One branch per non-trivial Bugzilla ticket 
topic/jhannah_crazy_idea
   Branches for unstable/unfinished work
stable
   Release manager pulls from master to stable periodically (all tests are passing, etc.)
release-#-#-#
   Pulled from stable, pushed to CPAN
attic/*
   Any branch with no activity for 1 year
I like it.
> Re: deletion of branches, I'm only really in support of deleting feature branches that have been merged back to 'master' or another branch (e.g. only removed using 'git branch -d foo').  Older subversion release branches don't tend to fall into that category, in that we had merged or cherry-picked changes from svn trunk to them, not vice versa; they were never merged back to trunk.  Deletion in this case would be somewhat history-revising, correct?
I'm fine with attic/ and just leaving stuff in there until 2050. Then we should probably delete them.  :)
My understanding is that by default commits that have no pointers to them (branches or tags or subsequent commits) are subject to cleanup/prune. I think this means that if someone, 10 years ago, committed 3 times to the branch "jhannah_crazy_idea" and that branch is deleted, then those 3 commits may be removed (gone forever) by git cleanup/prune.
This is a feature or a crime against humanity depending on who you ask. It can be disabled in a normal repo, I don't know about github. 
> Saying that, we could adopt a workflow policy that allows deletion of any merged branch.  All this suggests coming up with a good 'Contributing' document.  Our 'Using Git' is a start towards this, but it's more a general use page and could point to other (possibly better) resources.  I would like something a bit more focused to demonstrate example work-flows and standard practices for those new to git and to BioPerl.  It should also mention how we handle pull requests and other github-related bits.
As I collect clues I'll be brain dumping everything I think I know onto the wiki. This is a crazy busy week for me though.  :(
Jay Hannah
http://biodoc.ist.unomaha.edu/wiki/User:Jhannah
    
    
More information about the Bioperl-l
mailing list