On Thu, Dec 11, 2014 at 06:47:06PM -0500, Clebert Suconic wrote: > We do a slightly different approach. If you guys are doing git I really think > you guys should consider it. > > 1. create a task branch : git checkout -b my-working-branch > > 2. create that voodoo that you do > > 3. when done, rebase your task branch on master : git rebase -i master > > 4. push to your github fork > 5. send a github Pull Request towards the github fork of the apache project > > 6. Someone else (yeah… someone who was not the original committer) should > merge it after review > > 7 That someone else will do: git merge --no-ff github/pr/PRNumber > ( We ellected to have merge committs with our committs, so we always have two > people to blame in case things go wrong) > > If you elect to not have the merge commit like we have, you can simply use > git pull.. and that should presever the Hashes from the original commit. > > 8. The apache bot will close the PR unless you rebased the commit (which you > are not supposed to) > > > > Why we do that? > > > I - to avoid merge errors like it just happened > II - it increases community > iii - we have a theory that everyone will do stupid things eventually... this > is an extra layer of protection :) > > > You could look at our README for more information: We are still getting > started with it and we have based this on how other apache projects are using > git and github: > > > https://github.com/apache/activemq-6/blob/master/README.md
I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgpVnaw8sVRxg.pgp
Description: PGP signature
