Am 2017-05-15 um 18:39 schrieb Gary Gregory:
I wonder of all the branches that are effectively temporary should be in a
"temp/" root to make it obvious this is short term like my
dev/4.4.x/HTTPCORE-466? Not great, but maybe less confusing?
I don't like that idea because you will never be able to define the
duration of temp, one day, week, months? The dev/ seems redundant to
because 4.4.x -- note the X implies development on a bugfix branch.
Michael
On Mon, May 15, 2017 at 9:34 AM, Michael Osipov <micha...@apache.org> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
