hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Git policies and practices
Date Wed, 10 May 2017 19:25:04 GMT
It would be helpful to document this on the Wiki and/or website

On 10 May 2017 at 20:22, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Wed, 2017-05-10 at 21:06 +0200, Michael Osipov wrote:
>> Hi folks,
>> given that Oleg finally took up the chance migrating core and client
>> to
>> a Git-based repo, we should agree how we are going to work with in
>> conformance with a good Git practice to avoid chaos on master. I'd
>> like
>> to provide an example first why a common practive is so necessary to
>> make life easier for us (committers) and as well as for our users
>> reading a beatiful log understanding what we do and why we do it.
>> Example: as you might know, there are about ten committers for Maven
>> and
>> we already use Git for quite some time, but did not really embrance
>> it's
>> workflow. It finally ended in having people constantly working on
>> master
>> pushing fixes for fixes and reverts for reverts (including myself),
>> rendering master unreadable and unusable. We agreed for a reset on
>> master (we actually skipped 3.4.0 for that reason) (INFRA did) and
>> went
>> through every single ticket wether it should be on 3.5.0 or not and
>> why.
>> The approach we have taken is that for every single ticket a branch
>> MNG-xxxx is created by a dev, pushed to origin. Jenkins will
>> automatically run all ITs. After that has happened you ask for a
>> review
>> on dev@ and leave room for discussion. There are oftern cases you
>> don't
>> see. Having an extra pair of eyes is helpful. This flow works very
>> well
>> because we now have a single-commit-per-issue, fully working, no
>> fiddling.
>> My proposal:
>> 1. Branch off master (git checkout -b HTTPCORE-XXXX master)
>> 2. Work on your issue. Create as many commits as you want
>> 3. Polish it
>> 4. Squash it/fix it up
>> 5. Ask for a review if you are uncertain
>> 6. merge back to master, but avoid merge commits which are just
>> noise
>> for a single merge (rebase your branch onto mater)
>> 7. Never rewrite (rebase) history on master because you will break
>> others. Infact, you can't because it is a protective branch. Only
>> can do.
>> 8. Take care of a proper commit message, these references are good:
>>    * https://chris.beams.io/posts/git-commit/
>>    * https://github.com/erlang/otp/wiki/Writing-good-commit-messages
>> Put the title of the JIRA issue (e.g., [HTTPCORE-123] Memory leak in
>> response) in the first line, followed by an explanation why you did
>> take
>> this approach. The ticket desc contains the issue, your commit
>> message
>> contains the solution.
>> 9. If in doubt, ask for help and give people a couple of days to
>> react.
>> 10. When you close the issue, put a link to your commit to create a
>> direct relation between issue and solution.
>> 11. If this change comes for a PR on GitHub, don't steal authorship,
>> let
>> the reporter polish his work and amend the message at the end with
>> "This
>> closes #xy" and push.
>> Something else I forgot?
>> What do you think?
>> Michael
>> PS: I know this is work, but it pays off really quick
> +1
> All makes sense to me. Pretty much every should happen on a dev
> (feature) branch and later merged to the release branch (like 4.3.x,
> 4.4.x, trunk).
> I would still ask for master being mutable (rewritable) or abandon the
> concept of a master branch as inapplicable in favor of a release branch
> such as 5.0.x.
> Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message