On Wed, 2017-05-10 at 21:06 +0200, Michael Osipov wrote: > 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 >
+1 All makes sense to me. Pretty much every should happen on a dev (feature) branch and later merged to the release branch (like 4.3.x, 4.4.x, trunk). I would still ask for master being mutable (rewritable) or abandon the concept of a master branch as inapplicable in favor of a release branch such as 5.0.x. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
