Re: [egit-dev] Granularity of changes

[Ferry Huberts <ferry.huberts@xxxxxxxxxx>]

 On 08/05/2010 04:37 PM, Benjamin Muskalla wrote:
> Hey there,
>
> I was working on a bug yesterday (bug 307112 for the sake of
> completeness). The problem:
> Not only bug fixing was neccessary but also several refactorings that
> make the code more readable. First off, I extracted several methods,
> commit, then refactored some of the logic how the dialog behaves,
> commit, and finally fixed the bug itself.
> In the past, I squashed all commits together and pushed them upstream.
> But I think the right thing to do is to push all of the steps to the
> repo to a) have a history that makes it easy to follow the development
> and b) give others a better possibility to follow my changes.
> Pushing all commits means that we need to review step by step instead
> of one bug chunk.
>
> What's your opinion on that? I'd prefer pushing the steps as separate
> commits but if the rest of the team thinks that the review overhead is
> too much, that's ok with me.
>
> Any comments on that one?
>
> Regards,
> Benny
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev

What works best most of the time:
- Make small commits, as small as reasonable. This makes them easy to review
- Each commit should have a commit message that explains very clearly
what the commit sets out to achieve (unless this is abundantly clear
from the code itself, which is basically only the case for trivial
patches). Also, when you fix a bug then report which bug you fix. When
there are deeper reasons for doing things the way the commit does, then
explain these as well. This all is for the reviewers and yourself: the
context of the commit is completely clear.
- Do not mix concerns in commits: have a commit do a single thing. This
makes them reviewable "in isolation". The purpose of the commit is clear
and can be understood easily by the reviewers and yourself.
- Do not break the build and tests for _any_ commit: this is very
important for bug hunting.
- Split your work into multiple smaller pieces of work (when possible)
and implement each of these pieces in a series of commits.
- A series of commits should work towards a 'feature' in a clear way and
only 'enable' the feature in the last commit of the series.
- In a series of commits first lay the groundwork and then build on that
towards the feature.
- Do not mix concerns in branches: when you encounter a bug while
working on something then create a new branch to fix the bug. If your
work depends on the bug being fixed then rebase your work on that new branch


These guidelines work very well for us at the Dutch DoD :-)

Disclaimer: I'm not an active contributor in this project so I might
have some fact not entirely straight. I sure hope thought that I nailed
them :-)

-- 
Ferry Huberts