Skip to content
This repository has been archived by the owner on Apr 22, 2024. It is now read-only.

Contributing

Jump to bottom
Antonio Mika edited this page May 26, 2017 · 4 revisions

TL;DR

  1. Clone the repository: git clone git@github.com:mhacks/mhacks-web.git
  2. Create a branch locally for your feature: git branch my-feature
  3. Checkout your branch: git checkout my-feature
    ----- to branch and checkout in one command: git checkout -b my-feature
  4. Implement your feature with as many commits as you'd like
  5. Run yarn run test to test your code against our CI. This will ensure that your code is formatted well (it will ask you if you want to autoformat certain files) and complies with eslint.
  6. Push your branch to GitHub: git push origin my-feature
  7. On GitHub click "Open Pull Request"
  8. Fill in the information for your pull request following the template
  9. Tag 1-2 people that you think might want to review it
  10. Get feedback, talk about the feedback, implement any agreed changes, commit them and push, repeat until you have all thumbs up (👍)
  11. Squash and merge on GitHub
  12. Profit?

MHacks Git Flow

Reviewing code ensures the quality of the codebase is upheld throughout development. Code quality isn't just having pretty syntax, but also includes architecture, comments/documentation, and file management. To uphold our quality we enforce that no code gets into the master branch without at least one approved review by an authorized reviewer.

If you are unfamiliar with git, go here for an introduction.

At MHacks, we have our master branch. We hold master sacred. master is the current state of the application, which may or may not be up to date with mhacks.org or staging.mhacks.org.

When working on a feature for mhacks, you will use branches. You will create a branch locally for your feature with an appropriate name, and you will do all your work there. Commit locally as much as you'd like and push to GitHub (on your branch) as much as you'd like. When you are ready for your feature to be reviewed, open a pull request.

A pull request is a request to merge the code in your feature into the master branch. In your pull request, make sure to say what GitHub Issue your branch fixes (e.g. "Fixes #78"), briefly describes what your feature does, attach screenshots if its a frontend fix, and say anything else that might be helpful during review. Look here for an example pull request.

Keeping your branch up to date

While working on your feature, it is likely that some commits may have been pushed to master before you are done working. It is convenient to keep your branch in sync with master to fix merge conflicts and get general updates before you open your pull request. Personally, I recommend rebasing your feature branch on top of master rather than merge commits. See here for a good explanation. To do this, run git rebase master while on your feature branch (make sure your master branch is up to date first).

Testing your code against the CI

All code that is pushed to GitHub will run through our Travis-CI. This will ensure that our code follows our standards and continues to be as readable and clean as possible. The CI will do two things. First it will run eslint as a static code analyzer to make sure code is clean, syntax error free, and ready for production. Next, it will run prettier which is a very well opinionated code formatter. It takes the effort out of ensuring our code follows good formatting standards and is easy to use. They can both be ran with yarn run test, which will first check the code with eslint for any errors. If there are no errors, prettier will do it's job, reporting to you the files that will be changed by the test. You can answer yes or no to allow prettier to continue.

Clone this wiki locally