[Kdenlive-devel] Git workflow

[Simon A. Eugster]

Hey Alberto, hey jb!

On 11/03/2011 04:36 PM, jb wrote:
> On Thursday 03 November 2011 08:49:22 Alberto Villa wrote:
>> Hi all!
>>
>> To complete svn2git rules I need your opinion on what will be our
>> preferred workflow in Git.
>>
>> First thing first, have a look here:
>> http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
>>
>> We could adopt it completely and have something like this:
>> - master: always stable, only gets bug fixes and production-ready
>> features;
>> - next (or whatever name you like): integration branch to test new
>> features during development, gets bug fixes (merged from master) and
>> features when there is something to test (i.e., no "breaking everything"
>> commits, but "add experimental support for X to Y" commits, merged
>> from feature branches), and it's the branch we and our bleeding edge
>> users will run;
>> - release branches: one for minor release (0.7, 0.8...), get merge commits
>> from master when ready to release - I'm afraid we need those to address
>> urgent bug fixes (see 0.7.7.1), otherwise tagging master would be just
>> easier;
>> - feature branches: local or remote, it's where "breaking everything"
>> commits go, be it features or complex bug fixes.
>
> I have no experience with git, so I am not the best person to comment. However
> it seems a good idea to have "master" that would always be in a "releasable"
> state (when translations are ready), and "next" that would be more like our
> current svn trunk.
>
> I am not sure about the "release" branches. We don't really have the energy to
> maintain several "stable" branches, so my idea would be that when we make a
> new Kdenlive release (from the "master" branch), we wait like 2 weeks before
> merging changes from the "next" branch. That way, if some serious issue
> appears in these 2 weeks after a release, we can easily make a new minor
> release fixing just a few bugs from the previous release.
>
> That would avoid having too many branches around... but again, I am not used
> to git so if anyone else thinks it's easier to branch releases, I am ok.

I agree; I'm not too experienced with git either, but I would try to 
keep the number of branches minimal as well. Is there something that 
speaks against using tags for releases and using a release branch instead?

Regarding the feature branches, if I understand correctly these are 
public private branches, i.e. for example when I decide to break the 
titler again and want to have my work backed up in git. So the rest of 
you can still go on developing in the «next» branch without all the 
segfaults I introduced in my feature branch (Until I merge them with the 
«next» branch). Right?