COVID-19 Digital Classroom

🚀 Quick start

1. Clone Repository

     git clone git@github.com:CommunityHealthAcademy/digital-classroom-landing-site.git

2. Start developing

   Navigate into the site's directory and start it up.

     cd digital-classroom-landing-site
     gatsby develop

   Your site is now running at http://localhost:8000!

   _Note: You'll also see a second link: _http://localhost:8000/___graphql_. This is a tool you can use to experiment with querying your data.

🧐 What's inside?

A quick look at the top-level files and directories you'll see in the project.

├── src
│   ├── components
│   └── pages
├── gatsby-browser.js
├── gatsby-config.js
├── gatsby-node.js
├── gatsby-ssr.js
└── package.json

1. /src: This directory will contain all of the code related to what you will see on the front-end of the site (what you see in the browser).

2. /components: This directory will contain all of the components you will see on the browser.

3. /pages: This directory will contain all of the pages you will see on the browser.

4. gatsby-browser.js: This file is where Gatsby expects to find any usage of the Gatsby browser APIs (if any). These allow customization/extension of default Gatsby settings affecting the browser.

5. gatsby-config.js: This is the main configuration file for a Gatsby site. This is where you can specify information about your site (metadata) like the site title and description, which Gatsby plugins you’d like to include, etc. (Check out the config docs for more detail).

6. gatsby-node.js: This file is where Gatsby expects to find any usage of the Gatsby Node APIs (if any). These allow customization/extension of default Gatsby settings affecting pieces of the site build process.

7. gatsby-ssr.js: This file is where Gatsby expects to find any usage of the Gatsby server-side rendering APIs (if any). These allow customization of default Gatsby settings affecting server-side rendering.

Commit Strategy

Our codebase uses commitlint which lints our commits to the conventional commits specification.

The way we structure our commits is as follows:

<type>(<optionalscope>): some sort of commit message

Type

Can be anything of:

build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test

scope

The scope is normaly the feature type i.e. footer. This is optional and not required in the commit

message

The message is normally an indication of what is added (or removed). It should summarise the main change made to the code base in that commit

Example commit

feat(footer): Add footer design

Full summary of conventional commits

summary