Skip to main content

Source Control

📜 General Rules​

Version Control Rules

  • All coding/development efforts need to be tracked through Git.
    • This includes: code, SQL scripts, build scripts, and any other text-based code deliverable.
  • Pull requests must be made to get any code merged into the "stable" branch.
  • All commits must adhere to the commit message standards.

...and always remember:

Gitflow diagram

✨ Branch Names​

Branch naming conventions should follow the pattern of:

PRODUCT/YOUR_USERNAME/#FEATURE_NUMBER-DESCRIPTION.

Example: omni/russell.green/#1234-update-user-guide-docs

📑 Commit Messages​

Rizing developer commit messages must adhere to the Conventional Commits Guide

Summary​

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

In general the pattern mostly looks like this:

type(scope?): subject  #scope is optional

Real world examples can look like this:

chore: run tests on travis ci
fix(server): send cors headers
feat(blog): add comment section

Common types according to commitlint-config-conventional (based on the the Angular convention) can be:

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

These can be modified by your own configuration.

🧾 Developer Workflow Summary​

High-Level Git Workflow

  1. Admin Creates a new ticket (ex: #1234) and assigns it to developer
  2. Developer Clones the repository and marks the ticket as "Active"
  3. Developer Creates a new feature branch (see branch naming), off of the current release branch, to start a new feature
  4. Developer Commits and pushes code to their feature branch
  5. Developer Creates a Pull Request to merge their feature branch into the active release branch
    1. An email is automatically sent to the admins and reviewers of the repository
    2. All project reviewers perform a code review and either Approve or Decline the PR
    3. Developer iterates on changes until all reviewers have Approved the PR
  6. Admin Merges PR into the active release branch. 1.1 This automatically accepts the Pull Request and the developer will be notified via email. 1.1 This automatically deletes the feature branch from origin