[Kmymoney-devel] Development workflow proposal

Alvaro Soliverez asoliverez at kde.org
Mon Nov 14 02:45:00 UTC 2011


Hello Jack,
I usually stick to a simpler workflow without using git stash and smaller
commits, which git encourages.

My usual workflow is the following:

git checkout master
git pull -r
git checkout -b bugxxx  <------ this creates a new branch
<write code, test>
git add <file1>
git commit <file1> <file2>
git checkout master
git pull -r
git checkout bugxxx
git rebase master
<solve conflicts, if any>
<write some more code>
git commit <file1>
git checkout master
git pull -r
git checkout bugxxx
git rebase master
<solve more conflicts, test>
git checkout master
git merge bugxxx
git push
git branch -d bugxxx <--- this is optional. it removes the branch


On Sun, Nov 13, 2011 at 5:29 PM, Jack <ostroffjh at users.sourceforge.net>wrote:

> On 2011.11.11 19:27, 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
>> - 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.
>>
>> Input is welcome, but please keep in mind that this only affects people
>> that will be actually pushing to the repository.
>>
>
> Is there a more detailed example of this (or a similar) workflow,
> including use of 'git add' and 'git stash?'  If I am editing a large
> section of the manual, I may work on it for over a week before I am ready
> to commit the changes, and I still want to be able to pull down any other
> changes from the repository, but I believe 'git pull --rebase' refuses to
> proceed if there are any uncommitted local changes.
>
> I've started reading the techbase entries on git, and I know I'll
> eventually be able to figure it out, but if there is already an appropriate
> tutorial or cookbook I just have not yet found, it would save me (and
> others?) a lot of time.
>
> Thanks.
>
> Jack
>
> ______________________________**_________________
> KMyMoney-devel mailing list
> KMyMoney-devel at kde.org
> https://mail.kde.org/mailman/**listinfo/kmymoney-devel<https://mail.kde.org/mailman/listinfo/kmymoney-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20111113/52431c23/attachment-0001.html>


More information about the KMyMoney-devel mailing list