[Kdenlive-devel] Git workflow
jb at kdenlive.org
Fri Nov 4 14:55:19 UTC 2011
On Friday 04 November 2011 15:11:40 you wrote:
> On Friday 04 November 2011 15:05:18 Alberto Villa wrote:
> > Last case I can think of: *.1 revision. You tag 0.x.y from master, and
> > then merge feature A to it. But people starts screaming that 0.x.y
> > removes root partition. So you checkout tag 0.x.y (all these tasks are
> > *instant*
> > Git), branch off from it, delete the "rm -rf /*` hidden in Kdenlive
> > configuration wizard, and tag 0.x.y.1 from the branch. To complete the
> > operation, you merge the branch into master (and solve potential
> > conflicts, should the `rm -rf /*` have been changed to `sudo rm -rf /*`
> > master).
> Oh, and you then merge master to next. ;)
Hi Alberto and all!
Thanks for the explanations! I now have read your mail 3 times and I think I
understood! So if I put it in other words, it would work like this:
* If I want to fix a simple thing:
- I work on it on my local copy of master and commit it directly to master,
then it is also merged to 'next'.
* If I want to work on something more complicated, ex. rewrite effect stack:
- I create a remote 'feature' branch from master
- I work on it and commit my changes to the branch, other people can also help
- When it is ready for testing, I merge my branch into 'next'
- Bug fixes go in my 'feature' branch and are merged again in 'next' for
- When it is stable, my 'feature' branch is merged into 'master', 'master' is
merged into 'next' and my remote 'feature' branch is deleted.
* Of course one can also work on a local branch of master for some reasons...
Now, I have 2 questions / comments:
1) What about string freeze? My proposal to wait a few weeks before merging
new features after a release was to make sure that no new string is introduced
if we make a .1 release. But then it would block development, so I think that
if we need to make a .1 release, it is probably better to do as you proposed:
create a new branch from the release tag, fix the problems in this branch,
create new release from that branch then merge changes to master.
2) Are some of the merges automated? I mean that if I fix a stupid bug in
'master', will it automatically be merged to 'next' or do I have to do it
We shoud probably set up a web page to list the commands for the most common
operations (create a branch, merge it to next, how to update your branch with
latest changes from master or next, ...)
More information about the Kdenlive