Skip to content

Latest commit

 

History

History
126 lines (89 loc) · 4.34 KB

commits.md

File metadata and controls

126 lines (89 loc) · 4.34 KB

Stage#1 > Clean Code S1E1

Git rules

Commits content requirements

Each commit should have

  • either completed functionality / documentation
  • either completed fix of a defect in code
  • either completed code refactoring

Long story short, all changes in a commit should be described by one sentence with a single predicate.

Why is it required?

  • When a mentor is reviewing your Pull Request, it will be easier for them to look through the list of commits and check the logic in each commit separately than review the code of the whole application.
  • If the logic of one commit is wrong, you will be able to revert it without interfering with other functionality.

Commits name requirements

  • Commits' name must follow the guideline
  • Present tense must be used (e.g. "add feature", not "added feature")
  • Imperative mood must be used (e.g. "move cursor to ...", not "moves cursor to ...")

Examples of commits' names

  • init: - is used for the beginning of a project or a task.

    Examples:

    init: start youtube task
init: start mentor-dashboard task

  • feat: – is used for adding a new feature (added zoom, added footer, updated product card etc.)

    Examples:

    feat: add basic page layout
feat: implement search box
feat: implement request to youtube API
feat: implement swipe for horizontal list
feat: add additional navigation button
feat: add banner
feat: add social links
feat: add physical security section
feat: add real social icons

  • fix: – is used for fixing some bugs.

    Examples:

    fix: implement correct loading data from youtube
fix: change layout for video items to fix bugs
fix: relayout header for firefox
fix: adjust social links for mobile

  • refactor: – code refactoring: application functionality wasn't changed, files were moved/created/deleted, code formatting changed, algorithms improved, but functional part is the same.

    Examples:

    refactor: change structure of the project
refactor: rename vars for better readability
refactor: apply eslint
refactor: apply prettier

  • docs: – is used for docs/README updates.

    Examples:

    docs: update readme with additional information
docs: update description of run() method

PR Requirements

Pull Request is a place to discuss code. It should not look like a student or mentor monologue. Be cultural, respect each other's time and work.

The Pull Request description should contain the following information:

  • A link to the task.
  • Screenshot of the result of the task (page of the created application or website). Add the screenshot to the Pull Request as an image.
  • A link to the deployed version of your application or website. You can use the following ways for the deployment:
    • gh-pages if there is a private repository of the school;
    • if there is no private repository of the school or if it is impossible to place the application on gh-pages of the school's private repository - netlify.com or other similar hosting.
    • for demos hosted on netlify.com, the site name is given as: github account name - task name.
  • Due Date / Deadline Date.
  • Your self-assessment with a preliminary grade.
  • It is recommended to add a link to a YouTube video of a self-check of the project you created (only for tasks that are cross-checked).

PR Example:

1. Task: [https://github.com/rolling-scopes-school/tasks/blob/master/tasks/fancy-weather.md]()
2. Screenshot: ![](https://docs.rs.school/images/fancy-weather.png)
3. Deploy: [https://chakapega-fancy-weather.netlify.com/]()
4. Done 28.05.2020 / deadline 31.05.2020
5. Score: 220 / 300

   – HTML, CSS, Design (15/30)

   – [x] The smallest available page width: 320px (10)
   – [±] UI is copied from the template or is even improved (5/10)
   – [ ] the application works correctly for each of the languages (0)
   – The "Weather for tomorrow" block contains the following data (15/20)

   – [x] weather and geolocation data (10)
   – [±] clocks that are updated every second (5/10)
   ...

6. YouTube link with self-check.

PR should not contain:

  • Commented code.
  • Some extra files, autogenerated code, node_modules folder etc. Use .gitignore for such cases. More