hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Git policies and practices
Date Mon, 15 May 2017 16:34:21 GMT

I have updated the link based on the input and put it onto the wiki:

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 
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!


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

View raw message