Hi folks,
given that Oleg finally took up the chance migrating core and client to
a Git-based repo, we should agree how we are going to work with in
conformance with a good Git practice to avoid chaos on master. I'd like
to provide an example first why a common practive is so necessary to
make life easier for us (committers) and as well as for our users
reading a beatiful log understanding what we do and why we do it.
Example: as you might know, there are about ten committers for Maven and
we already use Git for quite some time, but did not really embrance it's
workflow. It finally ended in having people constantly working on master
pushing fixes for fixes and reverts for reverts (including myself),
rendering master unreadable and unusable. We agreed for a reset on
master (we actually skipped 3.4.0 for that reason) (INFRA did) and went
through every single ticket wether it should be on 3.5.0 or not and why.
The approach we have taken is that for every single ticket a branch
MNG-xxxx is created by a dev, pushed to origin. Jenkins will
automatically run all ITs. After that has happened you ask for a review
on dev@ and leave room for discussion. There are oftern cases you don't
see. Having an extra pair of eyes is helpful. This flow works very well
because we now have a single-commit-per-issue, fully working, no fiddling.
My proposal:
1. Branch off master (git checkout -b HTTPCORE-XXXX master)
2. Work on your issue. Create as many commits as you want
3. Polish it
4. Squash it/fix it up
5. Ask for a review if you are uncertain
6. merge back to master, but avoid merge commits which are just noise
for a single merge (rebase your branch onto mater)
7. Never rewrite (rebase) history on master because you will break
others. Infact, you can't because it is a protective branch. Only INFRA
can do.
8. Take care of a proper commit message, these references are good:
* https://chris.beams.io/posts/git-commit/
* https://github.com/erlang/otp/wiki/Writing-good-commit-messages
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.
9. If in doubt, ask for help and give people a couple of days to react.
10. When you close the issue, put a link to your commit to create a
direct relation between issue and solution.
11. 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 #xy" and push.
Something else I forgot?
What do you think?
Michael
PS: I know this is work, but it pays off really quick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
