On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote: > Folks, > > I have updated the link based on the input and put it onto the wiki: > https://wiki.apache.org/HttpComponents/GitGuidelines > > Here is verbatim copy: > = Typical Issue Workflow = > > 1. Branch off master ({{{git checkout -b <branch>/<JIRA id> > master}}}) > where {{{<branch>}}} is the branch you are going to apply the fix, > e.g., > 4.4.x or 5.0.x and {{{<JIRA id>}}} being the JIRA you have assigned > to > yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout > -b > 4.4.x/HTTPCORE-123 master}}}. > 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 master > 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 > 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. > > > Something else I forgot? > What do you think? > > Please comment! > > Michael >
Michael Could you please replace references to master with a 'release branch'? In fact, I propose we abandon master altogether in favor of a versioned release branch like 5.0.x Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
