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

[Heikki Lehvaslaiho]

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.

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



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
>