[Kmymoney-devel] Development workflow proposal

[Thomas Baumgart]

Hi,

I just tried the workflow described with that one liner that added a call to a 
dtor.

git show dcf183c20fa083302ca8a54614c62563852c19d1 on master and
git show ce50a11868339b60c82a6ad159078c917c27467d on 4.6

I forgot to add the -x to cherry-pick so you won't see a reference in the log 
message. Is there a way to preset the -x somehow/somewhere?

- more comments inline below -


on Saturday 12 November 2011 01:27:25 Alvaro Soliverez wrote:

> Hello all,
> if you are not an active KMM developer, you can stop reading here.
> 
> -----------------------------------------------------------
> With git there are several possible workflows, all of them correct, and
> suitable to different situations.
> I've had working experience with git in a context similar to ours (eg. a
> project with 5-6 developers, several branches, the possibility that we
> might modify the same files without knowing, etc.)
> In that project, what each of us would do was:
> - Pull --rebase the latest from the server for whatever branch we had to
> work in (master or stable)
> - Branch off to a private branch
> - Write the code, test, etc.
> - Commit
> - Switch to the original branch
> - Pull --rebase the latest again
> - Switch to work branch
> - Rebase from original branch
> - Fix conflicts if any, test again, commit if needed
> - Switch to original branch
> - Merge the work branch

Can we - at this point - delete the branch if we don't need it anymore to 
avoid cluttering the log?

> - Push to server
> 
> You can maintain several different branches. Keep in mind that branches are
> extremely cheap. It's totally different from SVN.
> 
> What rebasing means, is that it will get the commits from another branch,
> and it will try apply your commits on top of that. If there is a conflict,
> you have the opportunity to fix it while rebasing.
> 
> To summarize, this workflow means we always work on the code in private
> branches, then rebase and merge to master or stable branches.
> 
> In cases where a commit has to be applied to several branches, it can be
> merged to one branch, and cherry-picked from the others.
> 
> It is important to agree on a workflow that suits us, and also doesn't
> clutter the log, something that can happen very quickly on git.

From my current experience (and that is mostly local stuff and few trials on 
the KMyMoney git repo lately) the above sounds OK to me. Is this workflow in 
line with the global KDE workflow (documented somewhere on techbase I 
believe)?

> Input is welcome, but please keep in mind that this only affects people
> that will be actually pushing to the repository.

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
If it's there and you can see it, it's real.
If it's there and you can't see it, it's transparent.
If it's not there and you can see it, it's virtual.
If it's not there and you can't see it, it's gone.
-------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20111112/ddfd962e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20111112/ddfd962e/attachment-0001.sig>