[Bf-committers] How Merge master changes into remote branch

[Julien RIVAUD (_FrnchFrgg_)]

Le 21/11/2013 13:08, Wander Lairson Costa a écrit :
> 2013/11/20 Joshua Leung <aligorith at gmail.com>:
>> Good points Julien/_FrnchFrgg_
>>
>> I'm personally of the opinion that usage of rebase in general is a Bad
>> Thing (TM). For small/short-lived projects (or local feature branches for
>> small features), it's probably ok to use rebase (though again, that depends
>> heavily on the nature of how things developed).
I am a bit less categorical. I think that ideally short feature branches 
should be rebased with interactive to clean them up, then *merged with 
--no-ff*. See a better explanation than I could pull myself there: 
http://nvie.com/posts/a-successful-git-branching-model/ (the 
"Incorporating a finished feature on develop" paragraph). Note that all 
of this article is very good and a great inspiration for good workflow.

Long lived branches should be handled as master, that is people rebase 
--interactive before committing to them so that the history is cleanest 
and already reviewed when it is time to merge the branch into master. 
Note that this case is IMHO for bigger projects, especially when blender 
devs will be at ease with the parallelism of git developpement. Maybe 
the game engine could have its branch, etc...

_FrnchFrgg_