Statically generated site for Redbrick https://www.redbrick.dcu.ie
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

CONTRIBUTING.md 3.1 KiB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899
  1. # Contributing to Redbrick
  2. ## Code Contributions
  3. We welcomes new contributors.
  4. This document will guide you through the contribution process.
  5. ### Step 1: Fork
  6. Fork the project [on GitHub](https://github.com/redbrick/static-site) and check out your copy locally.
  7. #### Which branch?
  8. For developing new features and bug fixes, the `master` branch needs to be pulled
  9. and built upon. We follows a [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration)
  10. model, where the master branch is always deployed to production.
  11. ### Step 2: Branch
  12. Create a feature branch and start hacking:
  13. ```text
  14. $ git checkout -b my-feature-branch -t origin/master
  15. ```
  16. ### Step 3: Commit
  17. Make sure git knows your name and email address:
  18. ```text
  19. $ git config --global user.name "J. Random User"
  20. $ git config --global user.email "j.random.user@example.com"
  21. ```
  22. Writing good commit logs is important. A commit log needs to describe what
  23. changed and why. Follow these guidelines when writing one:
  24. 1. The first line ideally should be 50 characters or less and contain a short
  25. description of the change
  26. 1. Keep the second line blank.
  27. 1. Wrap all other lines at 72 columns.
  28. A good commit log can look something like this:
  29. ```
  30. explaining the commit in one line
  31. Body of commit message is a few lines of text, explaining things
  32. in more detail, possibly giving some background about the issue
  33. being fixed, etc. etc.
  34. The body of the commit message can be several paragraphs, and
  35. please do proper word-wrap and keep columns shorter than about
  36. 72 characters or so. That way `git log` will show things
  37. nicely even when it is indented.
  38. ```
  39. The header line needs to be meaningful; it is what other people see when they
  40. run `git shortlog` or `git log --oneline`.
  41. ### Step 4: Rebase
  42. Use `git rebase` (not `git merge`) to sync your work from time to time.
  43. ```text
  44. $ git fetch upstream
  45. $ git rebase upstream/master
  46. ```
  47. ### Step 5: Push
  48. ```text
  49. $ git push origin my-feature-branch
  50. ```
  51. Go to https://github.com/yourusername/static-site and select your feature branch.
  52. Click the 'Pull Request' button and fill out the form.
  53. Pull requests are usually reviewed within a few days. If there are comments
  54. to address, apply your changes in a separate commit and push that to your
  55. feature branch. Post a comment in the pull request afterwards; GitHub does
  56. not send out notifications when you add commits.
  57. ## Developer's Certificate of Origin 1.0
  58. By making a contribution to this project, I certify that:
  59. * (a) The contribution was created in whole or in part by me and I
  60. have the right to submit it under the open source license indicated
  61. in the file; or
  62. * (b) The contribution is based upon previous work that, to the best
  63. of my knowledge, is covered under an appropriate open source license
  64. and I have the right under that license to submit that work with
  65. modifications, whether created in whole or in part by me, under the
  66. same open source license (unless I am permitted to submit under a
  67. different license), as indicated in the file; or
  68. * (c) The contribution was provided directly to me by some other
  69. person who certified (a), (b) or (c) and I have not modified it.