Am 2017-05-15 um 20:18 schrieb Gary Gregory:
On Mon, May 15, 2017 at 11:13 AM, Michael Osipov <micha...@apache.org>
wrote:
Am 2017-05-15 um 19:35 schrieb Gary Gregory:
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
Which of the paths should we pick:
https://makandracards.com/makandra/527-squash-several-git-
commits-into-a-single-commit
The second option sounds like error prone busy work :-(
The second is the way to go. It is not errorprone. I have been doing this
for years. It just works. As soon as you get used to it, it'll feel very
natural. The only thing you need to remember to keep your branch updated
with your target branch.
I just did it with the first option.
How does it look to you?
As long as it does the same work, but consider that with the second
option your make a deliberate choice to select exactly those commits
your want to squash.
There are still a two issues:
1. For those who would like to do a review, they still need to list
through all commits, making it harder to read. I want to review a final
work and not an unpolished one.
2. It will not retain your commit, you will need an extra option for
that: http://stackoverflow.com/a/25930432/696632
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
