[Bioperl-l] git branches, tags, 'topic/bug_####'

[Chris Fields]

On May 13, 2010, at 11:48 AM, Heikki Lehvaslaiho wrote:

> I second Hilmar. Let's try to keep this simple.
> 
> While for most people just beginning to use git this discussion seems
> confusing and the structures complex, things really are pretty simple.
> 
> I expect most of the branches to live only in developers copies of the repo.
> They are created when work starts on the new bug or a feature, merged to
> master when work is done, and removed immediately or soon after that. Most
> of the work is done in the master and only the release managers touch the
> stable and release branches. See Jay's flow diagram.

Right, many branches will occur locally.  And I'm not suggesting that we strictly follow a particular pattern; I would rather not enforce that upon devs who already have a productive pattern set.  I think this would act more as a suggested method of development, something that has been demonstrated to work well for other large projects (and something I'll be following).

What I would really like to promote is using branches for making code changes, even ones that are only a few commits or so (and even if they are only local ones not pushed to github).  Branches are cheap.

> Work flow for this is (while calling 'git status' all the time):
> 
> git branch $new
> git checkout $new
> # work
> git commit
> git commit
> ...
> git checkout master
> git merge $new
> git push
> ...
> git branch -d $new
> 
>    -Heikki
> 
> Heikki Lehvaslaiho - skype:heikki_lehvaslaiho
> cell: +966 545 595 849  office: +966 2 808 2429
> 
> Computational Bioscience Research Centre (CBRC), Building #2, Office #4216
> 4700 King Abdullah University of Science and Technology (KAUST)
> Thuwal 23955-6900, Kingdom of Saudi Arabia

Yes, that's essentially the basic workflow, maybe with a preliminary 'git pull' to sync to the latest.

chris


> On 13 May 2010 18:43, Hilmar Lapp <hlapp at drycafe.net> wrote:
> 
>> 
>> On May 13, 2010, at 9:49 AM, Chris Fields wrote:
>> 
>> 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').
>>> 
>> 
>> I agree.
>> 
>> 
>>  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 wouldn't call it history-revising. I also think it's OK to delete release
>> branches that are no longer supported, iff we have a tag for the release
>> itself.
>> 
>> That's different from counting inactivity. A branch may lie dormant for a
>> year or longer until someone has time to pick it back up again - I don't see
>> the harm in keeping those around.
>> 
>> 
>> 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.
>>> 
>> 
>> That would be highly useful. I'll also voice a word of caution here though
>> - I find it kind of ironic that the switch to git, which is supposed to make
>> contribution *easier*, very often leads subsequently to complex
>> commit/pull/push/branching workflows being instituted for projects that take
>> pages and pages to document, a lot of time to ingest, and discipline to
>> follow - it seems to be very easy and tempting to go overboard with this.
>> 
>>       -hilmar
>> 
>> --
>> ===========================================================
>> : Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net :
>> ===========================================================
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l