Am 30.07.2013 19:53, schrieb Yves Blusseau:
> 
> Le 28 juil. 2013 à 19:28, KP Kirchdoerfer <kap...@users.sourceforge.net> a 
> écrit :
>> 
>> Yes, sounds easier and more towards how we do releases.
>> I'm keen to tag versions when doing a new release, so that won't be a
>> problem.
>> 
>> A question, possibly asked before, how do we keep branches like next in
>> sync with master/maint?
>> 
> 
> Like you do to merge maint into master: merge master into next:
> 
> git checkout next
> git pull --ff-only
> git merge origin/master
> 
>> E.g. I'd like to publish my work on new boot menu into something else
>> than master so it's available for testing, but don't harm master if
>> something is wrong.
>> 
> To do that use a topic branch (fork from master)
> 
>> Branch "next" would be a good place, but I assume it's that outdated
>> that doing a test within this branch may not give results I expect; the
>> same is true for pu, and will happen with other branches.
>> 
> 
> merge your topic branch into next
> 'next' branch "must" contain all the features in development so other users 
> can test the new features before they are merge into master when they are 
> stable.
> NEVER merge 'next' branch into master. Only merge stable topic branch into 
> master.
> 
>> In the wiki docs you've written that updating branches like next
>> "habitually" is not recommended.
>> 
>> So whats the recommended way to keep branches in sync?
>> 
> 
> Only merge integration branches (maint, master) upwards "NEVER" downwards. So 
> merge maint INTO master NEVER master INTO maint.
> 
> Merge master INTO next or pu "NEVER" next INTO master
> 
> Fork topic branches from master (or maint) and merge to integration branches 
> when topic branch is stable.
> 
> Merge topic branches into next so other users can test all new features that 
> will be released into master.
> 

Hi Yves

thx a lot for your patience to explaining it once again.
I understand the process more and hope I did it right with the latest
commits.
Now I have to get used to it...,
...and someone really test the commits to next.

kp

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to