From bea5775732890aecc0055fb09ba11683a12b86c9 Mon Sep 17 00:00:00 2001 From: kshitij-k-osmosys Date: Sun, 2 Feb 2025 19:59:16 +0530 Subject: [PATCH] docs: better formatting --- coding-standards/git.md | 90 ++++++++++++++++++++--------------------- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/coding-standards/git.md b/coding-standards/git.md index 825215c..4770803 100644 --- a/coding-standards/git.md +++ b/coding-standards/git.md @@ -27,7 +27,7 @@ This document outlines the standards and conventions for using Git within our co ## Git Configuration -- Username and Email: Ensure your Git configuration is set with your real name and work email. +- Username and Email: Ensure your Git configuration is set with your real name and work email. ```bash git config --global user.name "Your Name" @@ -36,41 +36,41 @@ This document outlines the standards and conventions for using Git within our co ## Repository Structure -- Main/Master Branch: - - Try to have `main` branch instead of `master`. - - The `main` branch should always be deployable. - - All commits on `main` should be made through pull requests. -- Development Branch: - - Use a `development` or `dev` branch for integration and testing. -- Set branch protection rules for `main` and `development` branches to restrict developers to push unverified changes and allow only maintainers to push/merge. Here is the quick read on how to set branch protection rules - - github: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule - - gitlab: https://docs.gitlab.com/ee/user/project/protected_branches.html -- Feature Branches: - - Create separate branches for individual features or bug fixes. - - Name them descriptively, e.g., `feature/user-authentication`, `bugfix/password-reset`. +- Main/Master Branch: + - Try to have `main` branch instead of `master`. + - The `main` branch should always be deployable. + - All commits on `main` should be made through pull requests. +- Development Branch: + - Use a `development` or `dev` branch for integration and testing. +- Set branch protection rules for `main` and `development` branches to restrict developers to push unverified changes and allow only maintainers to push/merge. Here is the quick read on how to set branch protection rules: + - github: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule + - gitlab: https://docs.gitlab.com/ee/user/project/protected_branches.html +- Feature Branches: + - Create separate branches for individual features or bug fixes. + - Name them descriptively, e.g., `feature/user-authentication`, `bugfix/password-reset`. ## Commit Messages -- Write clear, concise, and descriptive commit messages. -- Use the imperative mood ("add" instead of "added"). -- Start with a capital letter. -- Do not end the commit message with a period. - - Example: `Add user authentication` -- Always put your commit message in the below context & frame a proper message like this, - - If applied this commit will, \ - - Example 1: `Add validation to the email field` - - Example 2: `Update get users API response with lastname` +- Write clear, concise, and descriptive commit messages. +- Use the imperative mood ("add" instead of "added"). +- Start with a capital letter. +- Do not end the commit message with a period. + - Example: `Add user authentication` +- Always put your commit message in the below context & frame a proper message like this, + - If applied this commit will, \ + - Example 1: `Add validation to the email field` + - Example 2: `Update get users API response with lastname` ### Commit Message Format Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**: ```shell -: - - - -