Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification.
The "GitGuidelines" page has been changed by MichaelOsipov: https://wiki.apache.org/HttpComponents/GitGuidelines?action=diff&rev1=3&rev2=4 Comment: Update points ## page was renamed from GitPoliciesAndPractices This is a proposal/draft how we should coordinate our work after migrating HttpCore and HttpClient to Git. Especially to avoid a messy log. - Typical workflow when addressing an issue: + = Typical Issue Workflow = - 1. Branch off master ({{{git checkout -b HTTPCORE-XXXX master}}}) + 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 + 1. Polish it, squash it or fix it up into a single commit 1. Ask for a review if you are uncertain - 1. merge back to master, but avoid merge commits which are just noise for a single merge (rebase your branch onto mater) - 1. Never rewrite (rebase) history on master because you will break others - 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. + 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. 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. - 1. 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/fixes #xy" and push. + = 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: + 1.1. Apply the same above rules + 1.1. Don't steal authorship + 1.1. Let the reporter polish his work + 1.1. Amend the message at the end with "This closes/fixes #xy" and push. + --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
