hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: [VOTE] Git Guidelines (2)
Date Mon, 29 May 2017 19:51:48 GMT
Am 2017-05-24 um 19:11 schrieb Michael Osipov:
> Hi folks,
> I am re-casting this vote for the previously discussed Git guidelines
> for all committers to make life easier for everyone. If the vote passes,
> every committer must abide to this.
> The guidelines:
> = Typical Issue Workflow =
>  1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b
> <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}} being the
> JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or
> HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}.
>  1. Work on your issue and create as many commits as you want/need
>  1. Polish it, squash it or fix it up into a single commit
>  1. Ask for a review if you are uncertain
>  1. Take care of a proper commit message (good reads:
> [[https://chris.beams.io/posts/git-commit/|1]] and
> [[https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]):
> 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. If in doubt, ask for help and give people a
> couple of days to react.
>  1. Request the release manager to merge your banch back to the release
> branch and make sure that this merge won't incur a merge commit
>  1. When you close the issue, put a link to your commit to create a
> direct relation between issue and solution.
> =  Side Notes =
>  1. Never rewrite (rebase) history on master or any other long-lived
> branch because you will break others. Only the release manager is
> entitled to clean up history upto 72 hours after a commit if it is
> absolutely necessary
>  1. If a change comes for a PR on GitHub:
>    * Apply the same above rules
>    * Don't steal authorship
>    * Let the reporter polish his work
>    * Amend the message at the end with "This closes/fixes #xy" and push.
> Link: https://wiki.apache.org/HttpComponents/GitGuidelines
> Vote is open until 2017-05-29 00:00 Etc/UTC.


vote is over and no one except Oleg and me has voted.

What now? Will chaos reign our Git repos?


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

View raw message