docs: update git standards #77
Conversation
kshitij-k-osmosys
added
the
documentation
WalkthroughThe Git coding standards document has been restructured and updated for improved clarity and organization. Changes include updating the title level, adding an extensive table of contents, reformatting section headers, and expanding key areas such as Git configuration, repository structure, commit messages, and pull request guidelines. The document now uses inclusive terminology by renaming the default branch "Master" to "Main" and provides more detailed examples and links to additional resources. Changes
Suggested Reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
coding-standards/git.md (6)
1-23: TOC and Header Structure
The updated table of contents is extensive and improves document navigation. However, although the PR summary mentioned changing the document title from a level 1 to a level 2 heading, the title on line 1 remains as a level 1 header. Please confirm whether this was intentional. Additionally, several list items in the TOC appear to have inconsistent indentation; please review them against the markdown style guidelines (e.g. MD007).🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
18-18: Unordered list indentation
Expected: 4; Actual: 6(MD007, ul-indent)
37-51: Repository Structure Updates
The repository structure guidelines are well detailed, and the addition of branch protection rules alongside links to GitHub and GitLab documentation is useful. To improve clarity and adhere to markdown best practices, please consider:
- Formatting the bare URLs on lines 46–47 as clickable markdown links with descriptive text (e.g.,
[GitHub branch protection rules](https://docs.github.com/...)).- Reviewing the nested list indentations to conform with markdownlint recommendations.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
40-40: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
42-42: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
44-44: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
46-46: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
46-46: Bare URL used
null(MD034, no-bare-urls)
47-47: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
47-47: Bare URL used
null(MD034, no-bare-urls)
49-49: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
50-50: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
57-63: Commit Message Guidelines
The expanded instructions on commit messages, including the directive not to end messages with a period, add clarity. Please verify that abbreviations such as “etc.” are punctuated consistently throughout the document.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
58-58: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
60-60: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
61-61: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
62-62: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
64-80: Commit Message Format Example
The commit message format example is clear and instructive. For improved readability in tooling and documentation renderings, consider specifying a language for the fenced code block (for example, using “text”) instead of leaving it unspecified.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
68-68: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
86-103: Commit Type Descriptions
The list of commit types is comprehensive and helpful. A minor suggestion: in the “chore” description (line 91), adding a period after “etc.” would align with American English punctuation standards.🧰 Tools
🪛 LanguageTool
[style] ~91-~91: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...(ETC_PERIOD)
[misspelling] ~98-~98: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...(EN_COMPOUNDS_SEMI_COLONS)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...(ETC_PERIOD)
150-173: Pull Requests (PRs) Checklist Improvement
The checklist provided for pull requests is comprehensive and offers a strong reference for proper PR submission. Consider updating the phrasing “best practise” to “best practice” for consistency with American English, and ensure that the nested list items are indented consistently per markdownlint guidelines.🧰 Tools
🪛 LanguageTool
[grammar] ~160-~160: Use “the” before the superlative.
Context: ...ieve this> ``` - It is always a best practise to maintain checklist in ...(THE_SUPERLATIVE)
🪛 markdownlint-cli2 (0.17.2)
155-155: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
155-155: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
161-161: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
161-161: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
coding-standards/git.md(2 hunks)
🧰 Additional context used
🪛 LanguageTool
coding-standards/git.md
[style] ~91-~91: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...
(ETC_PERIOD)
[misspelling] ~98-~98: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...
(EN_COMPOUNDS_SEMI_COLONS)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...
(ETC_PERIOD)
[grammar] ~209-~209: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...
(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
coding-standards/git.md
18-18: Unordered list indentation
Expected: 4; Actual: 6
(MD007, ul-indent)
40-40: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
42-42: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
44-44: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
46-46: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
46-46: Bare URL used
null
(MD034, no-bare-urls)
47-47: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
47-47: Bare URL used
null
(MD034, no-bare-urls)
49-49: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
50-50: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
58-58: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
60-60: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
61-61: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
62-62: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
68-68: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
83-83: Bare URL used
null
(MD034, no-bare-urls)
84-84: Bare URL used
null
(MD034, no-bare-urls)
207-207: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
208-208: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
209-209: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
216-216: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
🔇 Additional comments (6)
coding-standards/git.md (6)
28-35: Git Configuration Section
The "Git Configuration" section is clear and the shell commands are correctly formatted with syntax highlighting. No changes are necessary here.
124-140: Commit Message Samples
The commit message samples are practical and varied. The examples are clear and provide a useful guide for drafting commit messages.
141-144: Revert Instructions
The revert commit guidelines are concise and clearly state the required format when reverting changes.
145-149: Commit Granularity
The guidance on making small, atomic commits effectively reinforces best practices. No issues noted here.
257-267: Tagging and Releases Section
The tagging and release section is succinct and practical with clear example commands. This section meets the documentation standards well.
268-271: Conclusion Section
The conclusion effectively reinforces adherence to Git standards and wraps up the document in a concise manner.
coding-standards/git.md
Outdated
| ## Submitting a Pull Request (PR) | ||
|
|
||
| Before you submit your Pull Request (PR) consider the following guidelines: | ||
|
|
||
| 1. Search the Pull Requests/Merge Requests of the respective project for an open or closed PR that relates to your submission. You don't want to duplicate effort. | ||
| 2. Fork the repository. | ||
| 3. Make your changes in a new git branch: | ||
|
|
||
| ```shell | ||
| git checkout -b my-fix-branch main | ||
| ``` | ||
|
|
||
| 4. Create your patch, **including appropriate test cases**. | ||
| 5. Follow our Coding Standards. | ||
| 6. Run the test suite of the respective project (if any), and ensure that all tests pass. | ||
| 7. Commit your changes using a descriptive commit message that follows our [commit message conventions](#commit-message-format). Adherence to these conventions is necessary because release notes are automatically generated from these messages. | ||
|
|
||
| ```shell | ||
| git commit -a | ||
| ``` | ||
|
|
||
| Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files. | ||
|
|
||
| 8. Push your branch to GitHub: | ||
|
|
||
| ```shell | ||
| git push origin my-fix-branch | ||
| ``` | ||
|
|
||
| 9. In GitHub, send a pull request to `main` branch. | ||
|
|
||
| 10. If the reviewer(s) suggests changes then: | ||
|
|
||
| - Make the required updates. | ||
| - Re-run the project test suites to ensure tests are still passing. | ||
| - Depends on the project: Rebase your branch and force push to your GitHub repository (this will update your Pull Request): | ||
|
|
||
| ```shell | ||
| git rebase main -i | ||
| git push -f | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Submitting a Pull Request – Numbering Inconsistency
The step-by-step instructions in this section are thorough; however, there is a numbering inconsistency. After the step “10. If the reviewer(s) suggests changes then:”, the list erroneously reverts to “8. Push your branch to GitHub:” before proceeding to “11. Create your pull request.” This could confuse users. Please rework the numbering so that the sequence remains sequential.
For example, consider this diff suggestion:
-8. Push your branch to GitHub:
- ```shell
- git push origin my-fix-branch
- ```
-11. Create your pull request.
+10. Push your branch to GitHub:
+ ```shell
+ git push origin my-fix-branch
+ ```
+11. Create your pull request.🧰 Tools
🪛 LanguageTool
[grammar] ~209-~209: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...
(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
207-207: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
208-208: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
209-209: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
coding-standards/git.md
Outdated
| #### After your pull request is merged | ||
|
|
||
| After your pull request is merged, you can safely delete your branch and pull the changes | ||
| from the main (upstream) repository: | ||
|
|
||
| - Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows: | ||
|
|
||
| ```shell | ||
| git push origin --delete my-fix-branch | ||
| ``` | ||
|
|
||
| - Check out the main branch: | ||
|
|
||
| ```shell | ||
| git checkout main -f | ||
| ``` | ||
|
|
||
| - Delete the local branch: | ||
|
|
||
| ```shell | ||
| git branch -D my-fix-branch | ||
| ``` | ||
|
|
||
| - Update your main with the latest upstream version: | ||
|
|
||
| ```shell | ||
| git pull --ff upstream main | ||
| ``` | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
After Your Pull Request is Merged
The post-merge instructions are clear and provide a useful checklist for cleaning up after a merge. Note that the heading “#### After your pull request is merged” (level 4) may be too deep in the hierarchy compared to preceding sections. Consider adjusting it to a level 3 heading to maintain a consistent heading increment throughout the document (see MD001).
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
216-216: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
coding-standards/git.md (7)
1-1: Heading Level Consistency:
The document title is defined as# Git Standards Document(a level 1 heading). However, according to the updated standards and the AI summary, the title should have been demoted to a level 2 heading. Please verify whether this change is intentional; if not, update the title to use## Git Standards Documentfor consistency with the new guidelines.
3-22: Table of Contents Formatting:
The newly added Table of Contents is comprehensive and enhances navigation. However, several nested list items (e.g., lines 8–14) use four-space indentation, which triggers markdownlint (MD007) warnings. To improve readability and adhere to the guidelines, consider re-indenting nested items with two spaces per level. Additionally, some bare URLs (lines 46–47 in the Repository Structure below) might benefit from being converted to markdown links.
37-51: Repository Structure Updates:
This section now distinguishes between branches more clearly. A couple of points for improvement:
- The heading “- Main/Master Branch:” still mixes terminology. For inclusivity and consistency, it might be better to use “Main Branch:” exclusively.
- The sub-bullets (especially those listing branch protection rules and associated URLs on lines 45–47) are indented with four spaces, resulting in markdownlint (MD007) warnings. Re-indent these sub-items to use two spaces per level. Additionally, consider converting bare URLs into proper markdown links to improve clarity and style.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
40-40: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
42-42: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
44-44: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
46-46: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
46-46: Bare URL used
null(MD034, no-bare-urls)
47-47: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
47-47: Bare URL used
null(MD034, no-bare-urls)
49-49: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
50-50: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
52-63: Commit Messages Guidelines:
The Commit Messages section is now detailed and sets clear expectations for writing commit messages. There’s just a minor stylistic note: in examples and bullet items, ensure that abbreviations such as “etc.” are properly punctuated in American English (e.g., “etc.” should include the period).🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
58-58: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
60-60: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
61-61: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
62-62: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
64-74: Fenced Code Block Language Specification:
In the "Commit Message Format" subsection, the example is enclosed within triple backticks without a language specifier. Adding a language tag (for example, use```textor```plaintext) would not only improve readability but also address markdownlint (MD040) concerns.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
68-68: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
150-177: Pull Requests (PRs) Guidelines:
The updated guidelines now include detailed bullet points and code examples for creating Pull Requests. The instructions are clear, and the numbering appears consistent. As with earlier sections, please review the indentation of the list items to ensure compliance with markdown standards.🧰 Tools
🪛 LanguageTool
[grammar] ~162-~162: Use “the” before the superlative.
Context: ...achieve this> ``` - It is always a best practise to maintain checklist in ...(THE_SUPERLATIVE)
🪛 markdownlint-cli2 (0.17.2)
156-156: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
164-164: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
40-50: Markdownlint & LanguageTool Considerations:
Several static analysis hints (e.g., MD007 for list indentation and MD034 for bare URLs) have been noted:
- Review and adjust the indentation for nested unordered list items across multiple sections (such as within the TOC and in the Repository Structure section).
- Convert bare URLs to proper markdown links where feasible.
Addressing these minor issues will tighten up the formatting and adherence to our markdown style guidelines.Also applies to: 211-213
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
40-40: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
42-42: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
44-44: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
46-46: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
46-46: Bare URL used
null(MD034, no-bare-urls)
47-47: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
47-47: Bare URL used
null(MD034, no-bare-urls)
49-49: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
50-50: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
coding-standards/git.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
coding-standards/git.md
[style] ~91-~91: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...
(ETC_PERIOD)
[misspelling] ~98-~98: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...
(EN_COMPOUNDS_SEMI_COLONS)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...
(ETC_PERIOD)
[grammar] ~162-~162: Use “the” before the superlative.
Context: ...achieve this> ``` - It is always a best practise to maintain checklist in ...
(THE_SUPERLATIVE)
[grammar] ~213-~213: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...
(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
coding-standards/git.md
40-40: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
42-42: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
44-44: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
46-46: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
46-46: Bare URL used
null
(MD034, no-bare-urls)
47-47: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
47-47: Bare URL used
null
(MD034, no-bare-urls)
49-49: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
50-50: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
58-58: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
60-60: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
61-61: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
62-62: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
68-68: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
83-83: Bare URL used
null
(MD034, no-bare-urls)
84-84: Bare URL used
null
(MD034, no-bare-urls)
156-156: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
164-164: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
211-211: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
212-212: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
213-213: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
🔇 Additional comments (8)
coding-standards/git.md (8)
24-26: Introduction Clarity:
The Introduction section succinctly outlines the purpose of the document. The content is clear and directly communicates the intent behind the Git standards.
28-35: Git Configuration Section:
The Git Configuration section now clearly provides guidance on setting your Git username and email with an example code block. The inclusion of a bash code block (```bash) is helpful. Consider, if necessary, adding a brief note about verifying your configuration after running these commands.
75-144: Commit Message Examples:
The sections covering "Commit Message Samples" and "Revert" provide solid examples and detailed instructions. The guidance is clear and helpful. No changes are required in these segments.🧰 Tools
🪛 LanguageTool
[style] ~91-~91: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...(ETC_PERIOD)
[misspelling] ~98-~98: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...(EN_COMPOUNDS_SEMI_COLONS)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...(ETC_PERIOD)
🪛 markdownlint-cli2 (0.17.2)
83-83: Bare URL used
null(MD034, no-bare-urls)
84-84: Bare URL used
null(MD034, no-bare-urls)
145-149: Commit Granularity:
The recommendations to keep commits small and atomic are straightforward and align with best practices.
178-219: Submitting a Pull Request (PR):
The step-by-step instructions for submitting a PR are comprehensive and sequential—from forking the repository to rebasing and force-pushing. The clear code snippets help illustrate the process well. Great job on ensuring the numbering is sequential and all steps are documented.🧰 Tools
🪛 LanguageTool
[grammar] ~213-~213: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
211-211: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
212-212: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
213-213: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
220-248: Post-Merge Cleanup Instructions:
The "After your pull request is merged" section provides clear, actionable steps for cleaning up local and remote branches and updating the main branch. This guidance is practical and well-structured.
249-270: Additional Sections (Code Reviews, Conflict Resolution & Tagging/Releases):
These sections effectively outline additional best practices including:
- Conducting code reviews before merging
- Promptly resolving merge conflicts
- Adhering to semantic versioning and tagging releases correctly
The content is clear and aids in ensuring a standardized workflow.
272-275: Conclusion Summary:
The Conclusion succinctly wraps up the document, reinforcing the importance of adhering to these standards. It caps off the document nicely, ensuring that teams are encouraged to follow the guidelines.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
coding-standards/git.md (6)
28-35: Git Configuration GuidanceThe instructions for configuring Git (including setting the username and email) are straightforward and well demonstrated through the code block. Consider adding a brief note to remind users to replace placeholders with their actual credentials.
37-51: Repository Structure UpdatesThe Repository Structure section effectively outlines branch naming conventions and protection rules—especially the shift from "master" to "main." For improved readability, consider formatting the URLs (lines 46–47) as proper Markdown links rather than bare URLs.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~40-~40: You might be missing the article “a” here.
Context: ... - Main/Master Branch: - Try to havemainbranch instead ofmaster. - Th...(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~45-~45: This verb may not be in the correct form. Consider using a different form for this context.
Context: ...ent` branches to restrict developers to push unverified changes and allow only maint...(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
🪛 markdownlint-cli2 (0.17.2)
46-46: Bare URL used
null(MD034, no-bare-urls)
47-47: Bare URL used
null(MD034, no-bare-urls)
52-63: Commit Messages Section EnhancementThe expanded Commit Messages section offers detailed guidelines and practical examples for crafting commit messages. There is a minor phrasing concern on line 60; the text
"If applied this commit will, <your commit message>"
could be reworded for clarity (e.g., "If applied, use the following format for your commit message: <your commit message>").
64-80: Commit Message Format and Header GuidelinesThe description and code example for the commit message format—including header, body, and footer—is clearly laid out. To improve clarity, consider revising the phrasing around line 78; for example, "This ensures that each line remains within 100 characters and is easily readable in various Git tools."
🧰 Tools
🪛 LanguageTool
[uncategorized] ~80-~80: You might be missing the article “the” here.
Context: ...e easier to read in various git tools. Footer should contain a closing reference to a...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
81-85: Footer Section ClarityThe Footer guidelines clearly state the need to include closing references (for issues) and provide useful URLs. For consistency with Markdown best practices, consider converting the bare URLs into formatted links.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~81-~81: Possible missing comma found.
Context: ...hould contain a closing reference to an issue if any. - github: https://docs.github....(AI_HYDRA_LEO_MISSING_COMMA)
🪛 markdownlint-cli2 (0.17.2)
83-83: Bare URL used
null(MD034, no-bare-urls)
84-84: Bare URL used
null(MD034, no-bare-urls)
179-220: Detailed PR Submission GuidelinesThe step-by-step instructions for submitting a PR are comprehensive and easy to follow. The numbered list and embedded code blocks provide a clear roadmap. One minor suggestion is to add a comma after "reviewer(s)" in step 10 (line 210) for improved readability.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~208-~208: The preposition “on” seems more likely in this position than the preposition “in”.
Context: ...it push origin my-fix-branch ``` 9. In GitHub, send a pull request tomainb...(AI_EN_LECTOR_REPLACEMENT_PREPOSITION_IN_ON)
[uncategorized] ~208-~208: You might be missing the article “the” here.
Context: ...9. In GitHub, send a pull request tomain` branch. 10. If the reviewer(s) su...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[uncategorized] ~210-~210: Possible missing comma found.
Context: ...ranch. 10. If the reviewer(s) suggests changes then: - Make the required updates. ...(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~214-~214: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
212-212: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
213-213: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
214-214: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
coding-standards/git.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
coding-standards/git.md
[uncategorized] ~40-~40: You might be missing the article “a” here.
Context: ... - Main/Master Branch: - Try to have main branch instead of master. - Th...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~45-~45: This verb may not be in the correct form. Consider using a different form for this context.
Context: ...ent` branches to restrict developers to push unverified changes and allow only maint...
(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
[uncategorized] ~80-~80: You might be missing the article “the” here.
Context: ...e easier to read in various git tools. Footer should contain a closing reference to a...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[uncategorized] ~81-~81: Possible missing comma found.
Context: ...hould contain a closing reference to an issue if any. - github: https://docs.github....
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~91-~91: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...
(ETC_PERIOD)
[misspelling] ~98-~98: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...
(EN_COMPOUNDS_SEMI_COLONS)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...
(ETC_PERIOD)
[uncategorized] ~102-~102: You might be missing the article “a” here.
Context: ...nce case Type or project shortcode as prefix. #### Subject The subject contains su...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~106-~106: You might be missing the article “a” here.
Context: ...ix. #### Subject The subject contains succinct description of the change: - use the i...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~109-~109: You might be missing the article “the” here.
Context: ...anged" nor "changes" - don't capitalize first letter - no dot (.) at the end #### Bo...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[grammar] ~163-~163: Use “the” before the superlative.
Context: ...eve this change ``` - It is always a best practise to maintain checklist in ...
(THE_SUPERLATIVE)
[uncategorized] ~163-~163: You might be missing the article “a” here.
Context: ...t is always a best practise to maintain checklist in every PR to make sure everything is ...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~163-~163: Possible missing article found.
Context: ... submitted properly along with your PR. Example checklist can be as follows: ```te...
(AI_HYDRA_LEO_MISSING_AN)
[uncategorized] ~208-~208: The preposition “on” seems more likely in this position than the preposition “in”.
Context: ...it push origin my-fix-branch ``` 9. In GitHub, send a pull request to main b...
(AI_EN_LECTOR_REPLACEMENT_PREPOSITION_IN_ON)
[uncategorized] ~208-~208: You might be missing the article “the” here.
Context: ... 9. In GitHub, send a pull request tomain` branch. 10. If the reviewer(s) su...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[uncategorized] ~210-~210: Possible missing comma found.
Context: ...ranch. 10. If the reviewer(s) suggests changes then: - Make the required updates. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~214-~214: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...
(SENT_START_DEPENDS)
[uncategorized] ~226-~226: Possible missing comma found.
Context: ...ository: - Delete the remote branch on GitHub either through the GitHub web UI or you...
(AI_HYDRA_LEO_MISSING_COMMA)
🪛 markdownlint-cli2 (0.17.2)
coding-standards/git.md
46-46: Bare URL used
null
(MD034, no-bare-urls)
47-47: Bare URL used
null
(MD034, no-bare-urls)
83-83: Bare URL used
null
(MD034, no-bare-urls)
84-84: Bare URL used
null
(MD034, no-bare-urls)
212-212: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
213-213: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
214-214: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
🔇 Additional comments (15)
coding-standards/git.md (15)
1-23: Review the Title and Table of Contents StructureThe updated Table of Contents is comprehensive and well-organized. However, the document title on line 1 remains a level 1 heading ("# Git Standards Document"), whereas the high-level summary mentioned switching to a level 2 heading. Please verify whether the title should be demoted to level 2 for consistency with the new document structure.
24-27: Introduction Section ClarityThe Introduction section is clear and concise, providing a solid context for the standards. No further changes are needed here.
86-103: Commit Type EnumerationThis section provides a thorough enumeration of commit types with clear examples. It covers a broad range of commit categories and aligns with best practices.
🧰 Tools
🪛 LanguageTool
[style] ~91-~91: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...(ETC_PERIOD)
[misspelling] ~98-~98: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...(EN_COMPOUNDS_SEMI_COLONS)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...(ETC_PERIOD)
[uncategorized] ~102-~102: You might be missing the article “a” here.
Context: ...nce caseTypeor project shortcode as prefix. #### Subject The subject contains su...(AI_EN_LECTOR_MISSING_DETERMINER_A)
104-111: Commit Subject GuidelinesThe instructions for writing the commit subject are concise and informative—emphasizing the imperative mood along with formatting rules. No changes are necessary.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~106-~106: You might be missing the article “a” here.
Context: ...ix. #### Subject The subject contains succinct description of the change: - use the i...(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~109-~109: You might be missing the article “the” here.
Context: ...anged" nor "changes" - don't capitalize first letter - no dot (.) at the end #### Bo...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
112-116: Commit Body InstructionsThe guidelines for writing the commit body are clear and emphasize the need to include motivation and context. This section is well written.
117-123: Commit Footer GuidelinesThe Footer instructions (including how to denote Breaking Changes) are clear and offer useful direction for referencing related issues. This section meets expectations.
124-140: Commit Message SamplesThe samples provided cover multiple styles (lowercase, Sentence case, and project shortcodes), which is very helpful for users. The examples are practical and enhance understanding of the commit conventions.
141-144: Revert InstructionsThe revert guidelines are concise and clearly explain the formatting requirements for reverting commits. No issues detected.
145-149: Commit GranularityThe emphasis on making small, atomic commits is well stated and reinforces best practices. This section is succinct and effective.
150-157: Pull Requests (PRs) OverviewThis section neatly summarizes key considerations for creating PRs, including the importance of a clean commit history and thorough review. The guidelines here are clear and helpful.
221-249: Post-Merge InstructionsThe "After your pull request is merged" section offers detailed, actionable steps for cleaning up branches and syncing with the upstream repository. The instructions are clear and should be very useful to users.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~226-~226: Possible missing comma found.
Context: ...ository: - Delete the remote branch on GitHub either through the GitHub web UI or you...(AI_HYDRA_LEO_MISSING_COMMA)
250-255: Code Reviews SectionThe Code Reviews guidelines are concise and effectively reinforce the importance of peer reviews and CI validation. This section meets the documentation standards.
256-261: Conflict Resolution GuidelinesThe instructions for resolving merge conflicts are straightforward and stress the need for local resolution and testing. This section is well formulated.
262-272: Tagging and ReleasesThe Tagging and Releases section effectively explains the principles of semantic versioning and provides executable Git commands as examples. It is clear and user-friendly.
273-276: Conclusion ClarityThe Conclusion succinctly reinforces the central importance of adhering to these Git standards. It serves as a strong closing statement for the document.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
coding-standards/git.md (5)
40-58: Repository Structure Clarity
This section is comprehensive and covers key areas such as the main branch, development branch, branch protection rules, and feature branches. One minor suggestion: in the bullet point starting at line 55 regarding branch naming, consider rewording"Accepted formats are using task
typeas prefix, forward slash/, followed by a shortkebab-case-description"
to something like:
"Accepted formats use a task type prefix (followed by a/and a short kebab-case description)"
for improved clarity and grammatical accuracy.🧰 Tools
🪛 LanguageTool
[grammar] ~55-~55: The word ‘task’ is not correct in this context. Consider using the plural form, adding a determiner like ‘the’ or ‘a’, or adding a preposition like ‘at’ or ‘in’.
Context: ...g fixes. - Accepted formats are using tasktypeas prefix, forward slash/, fo...(BE_VBG_NN)
🪛 markdownlint-cli2 (0.17.2)
51-51: Bare URL used
null(MD034, no-bare-urls)
52-52: Bare URL used
null(MD034, no-bare-urls)
93-108: Commit Types Clarification
The list of commit types is comprehensive. A couple of language tweaks are advised:
- In the chore entry, consider adding a period after “etc.” (or rephrasing for clarity).
- In the style entry, update “missing semi-colons” to “missing semicolons” to correct the spelling.
These are minor nitpicks that will help maintain consistency with written standards.🧰 Tools
🪛 LanguageTool
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...(ETC_PERIOD)
[misspelling] ~105-~105: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...(EN_COMPOUNDS_SEMI_COLONS)
[style] ~105-~105: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...(ETC_PERIOD)
170-182: PR Submission Checklist
The checklist is comprehensive and very useful for ensuring PR quality. One language suggestion: consider rewording"It is always a best practise to maintain checklist in every PR"
to
"It is always best practice to maintain a checklist in every PR"
for improved clarity and grammatical correctness.🧰 Tools
🪛 LanguageTool
[grammar] ~170-~170: Use “the” before the superlative.
Context: ...eve this change ``` - It is always a best practise to maintain checklist in ...(THE_SUPERLATIVE)
186-227: Submitting a Pull Request Steps
The step-by-step instructions for submitting a PR are detailed and easy to follow. One small note: in the step that begins with"Depends on the project: Rebase your branch and force push to your GitHub repository ..."
the static analysis indicates a pronoun may be missing. Consider rephrasing to something like:
"If applicable, depending on the project, rebase your branch and force push to update your Pull Request:"
to clarify the instruction.🧰 Tools
🪛 LanguageTool
[grammar] ~221-~221: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
219-219: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
220-220: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
221-221: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
1-283: Overall Document Structuring & Language Adjustments
The updated Git standards document is comprehensive and well-organized, with a detailed table of contents and clear step-by-step instructions. A few minor language and formatting tweaks (e.g. heading level clarification, slight rewording for grammatical accuracy, and attention to markdown list indentation and bare URLs) will further polish the document. Please review the suggested changes to ensure consistency with our internal guidelines.🧰 Tools
🪛 LanguageTool
[grammar] ~55-~55: The word ‘task’ is not correct in this context. Consider using the plural form, adding a determiner like ‘the’ or ‘a’, or adding a preposition like ‘at’ or ‘in’.
Context: ...g fixes. - Accepted formats are using tasktypeas prefix, forward slash/, fo...(BE_VBG_NN)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...(ETC_PERIOD)
[misspelling] ~105-~105: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...(EN_COMPOUNDS_SEMI_COLONS)
[style] ~105-~105: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...(ETC_PERIOD)
[grammar] ~170-~170: Use “the” before the superlative.
Context: ...eve this change ``` - It is always a best practise to maintain checklist in ...(THE_SUPERLATIVE)
[grammar] ~221-~221: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
51-51: Bare URL used
null(MD034, no-bare-urls)
52-52: Bare URL used
null(MD034, no-bare-urls)
90-90: Bare URL used
null(MD034, no-bare-urls)
91-91: Bare URL used
null(MD034, no-bare-urls)
219-219: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
220-220: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
221-221: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
coding-standards/git.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
coding-standards/git.md
[grammar] ~55-~55: The word ‘task’ is not correct in this context. Consider using the plural form, adding a determiner like ‘the’ or ‘a’, or adding a preposition like ‘at’ or ‘in’.
Context: ...g fixes. - Accepted formats are using task type as prefix, forward slash /, fo...
(BE_VBG_NN)
[style] ~98-~98: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...
(ETC_PERIOD)
[misspelling] ~105-~105: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...
(EN_COMPOUNDS_SEMI_COLONS)
[style] ~105-~105: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...
(ETC_PERIOD)
[grammar] ~170-~170: Use “the” before the superlative.
Context: ...eve this change ``` - It is always a best practise to maintain checklist in ...
(THE_SUPERLATIVE)
[grammar] ~221-~221: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...
(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
coding-standards/git.md
51-51: Bare URL used
null
(MD034, no-bare-urls)
52-52: Bare URL used
null
(MD034, no-bare-urls)
90-90: Bare URL used
null
(MD034, no-bare-urls)
91-91: Bare URL used
null
(MD034, no-bare-urls)
219-219: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
220-220: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
221-221: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
🔇 Additional comments (18)
coding-standards/git.md (18)
1-1: Heading Level Clarification
The title currently appears as a level 1 heading (# Git Standards Document), but the AI summary mentioned updating the title level (from level 1 to level 2) for consistency with the updated standards. Please confirm whether the title should be demoted to a level 2 heading (i.e. using##) or if the level 1 is the intended style.
3-7: Introduction & Table of Contents Headings
The “Introduction” section and its subsequent components are clearly defined. Ensure that the change in heading levels throughout (e.g. “## Introduction” and “## Table of Contents”) is intentional and consistent with overall documentation standards.
7-30: Table of Contents Structure
The new, extensive table of contents provides excellent navigation with clear links to each section. Please check that the nested list indentations comply with our markdown style guidelines (e.g. MD007 warnings regarding unordered list indentation) and adjust if needed.
31-38: Git Configuration Section
The Git configuration instructions—including the bash code snippet—are concise and clear. Ensure that the placeholders (like"Your Name"and"[email protected]") match our company standards or are updated in later revisions.
59-70: Commit Messages Guidelines
The commit message guidelines are well detailed and include practical examples. The instructions regarding style (imperative mood, no trailing period, etc.) are clear.
71-82: Commit Message Format Section
The explanation of the commit message structure (header, body, footer) along with the code snippet providing the template is excellent. No issues noted.
111-118: Commit Subject Guidelines
The subject guidelines are succinct and instructive—emphasizing the imperative mood and proper punctuation. No changes required here.
119-128: Commit Body and Footer Instructions
The guidance for writing the commit body and footer is clear. The inclusion of instructions regarding motivation and referencing issues (e.g. for closing issues) makes this section very informative.
129-130: Breaking Changes Note
The instructions for flagging breaking changes (using “BREAKING CHANGE:”) are clear and easy to follow.
131-146: Commit Message Samples
The sample commit messages are practical and cover multiple styles (lowercase, Sentence case, project shortcode). This helps users understand the expected format.
148-151: Revert Commit Guidelines
The instructions on how to format commit messages for reverts are straightforward. It clearly distinguishes how a revert commit should be structured.
152-156: Commit Granularity
The emphasis on making small, atomic commits is effective. This section succinctly reinforces best practices for commit granularity.
157-163: Pull Requests (PRs) Guidance
The guidelines for creating pull requests are clearly outlined and encourage thorough descriptions and context sharing. No further changes required here.
228-238: Post-Merge Instructions
The instructions provided after merging a pull request (deleting remote branches, checking out the main branch, etc.) are clear and practical.
257-262: Code Reviews Section
The “Code Reviews” section emphasizes the importance of thorough reviews and CI checks before merging. It is concise and effective.
263-268: Conflict Resolution Guidelines
The conflict resolution instructions are clear and stress the need to test changes locally after resolving conflicts. No issues noted.
269-279: Tagging and Releases
The guidelines for semantic versioning and creating release tags are straightforward and the included code snippet is clear.
280-283: Conclusion Section
The conclusion nicely wraps up the document by reiterating the importance of adhering to these Git standards. It is succinct and motivational.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
coding-standards/git.md (6)
58-59: Fix bare URLs in the documentation.The URLs should be properly formatted as Markdown links for better readability and maintainability.
Apply this diff:
- - 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 + - GitHub: [Managing branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) + - GitLab: [Protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html)🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
58-58: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
58-58: Bare URL used
null(MD034, no-bare-urls)
59-59: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
59-59: Bare URL used
null(MD034, no-bare-urls)
65-66: Improve branch naming format explanation.The explanation of branch naming formats could be clearer and more consistent.
Apply this diff:
- - Accepted naming formats are using task [type](#type) as prefix, forward slash `/`, followed by a short `kebab-case-description`. - - Examples: `feature/user-authentication`, `bugfix/password-reset`, `chore/update-api-version` etc. + - Branch names should follow this format: `<type>/<kebab-case-description>`, where: + - `<type>` is one of the commit types listed in the [Type section](#type) + - `<kebab-case-description>` is a brief, hyphenated description + - Examples: + - `feature/user-authentication` + - `bugfix/password-reset` + - `chore/update-api-version`🧰 Tools
🪛 LanguageTool
[grammar] ~65-~65: The word ‘task’ is not correct in this context. Consider using the plural form, adding a determiner like ‘the’ or ‘a’, or adding a preposition like ‘at’ or ‘in’.
Context: ... - Accepted naming formats are using task type as prefix, forward slash ...(BE_VBG_NN)
🪛 markdownlint-cli2 (0.17.2)
65-65: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
66-66: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
100-101: Fix bare URLs in issue closing references.The URLs should be properly formatted as Markdown links.
Apply this diff:
-- github: https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/closing-an-issue -- gitlab: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically +- GitHub: [Closing issues using keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/closing-an-issue) +- GitLab: [Closing issues automatically](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
100-100: Bare URL used
null(MD034, no-bare-urls)
101-101: Bare URL used
null(MD034, no-bare-urls)
180-192: Improve PR checklist formatting and content.The checklist could be better formatted and more comprehensive.
Apply this diff:
-- It is always a best practise to maintain checklist in every PR to make sure everything is submitted properly along with your PR. Example checklist can be as follows: +- It is always best practice to maintain a checklist in every PR to ensure everything is submitted properly. Here's a recommended checklist: ```text - [ ] No build errors - [ ] No linting issues - [ ] No formatting issues - [ ] Changes Tested Locally - [ ] Added PR title as per standards - [ ] Added PR description as per standards - [ ] Attached document link - [ ] Attached test cases file - [ ] Updated deployment checklist + ## Pre-submission Checks + - [ ] No build errors + - [ ] No linting issues + - [ ] No formatting issues + - [ ] Changes tested locally + + ## Documentation + - [ ] PR title follows standards + - [ ] PR description follows standards + - [ ] Relevant documentation updated + - [ ] Test cases documented + + ## Deployment + - [ ] Deployment checklist updated + - [ ] No breaking changes introduced + - [ ] Required configuration changes documented🧰 Tools
🪛 LanguageTool
[grammar] ~180-~180: Use “the” before the superlative.
Context: ...eve this change ``` - It is always a best practise to maintain checklist in ...(THE_SUPERLATIVE)
[uncategorized] ~180-~180: Possible missing article found.
Context: ...t is always a best practise to maintain checklist in every PR to make sure everything is ...(AI_HYDRA_LEO_MISSING_A)
[uncategorized] ~180-~180: Possible missing article found.
Context: ... submitted properly along with your PR. Example checklist can be as follows: ```te...(AI_HYDRA_LEO_MISSING_AN)
229-231: Fix list formatting and grammar.The indentation and grammar in the reviewer suggestions section need improvement.
Apply this diff:
- - Make the required updates. - - Re-run the project test suites to ensure tests are still passing. - - Depends on the project: Rebase your branch and force push to your GitHub repository (this will update your Pull Request): +- Make the required updates +- Re-run the project test suites to ensure tests are still passing +- If required by the project: + - Rebase your branch and force push to your GitHub repository (this will update your Pull Request)🧰 Tools
🪛 LanguageTool
[grammar] ~231-~231: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...(SENT_START_DEPENDS)
🪛 markdownlint-cli2 (0.17.2)
229-229: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
230-230: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
231-231: Unordered list indentation
Expected: 0; Actual: 2(MD007, ul-indent)
294-294: Improve release notes documentation link.The link to GitHub's auto-generate release notes feature should be properly formatted.
Apply this diff:
-- Projects hosted on GitHub can take advantage of the [auto-generate release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) feature. +- Projects hosted on GitHub can take advantage of the [automatically generated release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) feature to streamline the release process.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
coding-standards/git.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
coding-standards/git.md
[duplication] ~15-~15: Possible typo: you repeated a word.
Context: ...(#mainmaster-branch) - Development Branch - [Branch Protection Rules](#branch-protection-ru...
(ENGLISH_WORD_REPEAT_RULE)
[grammar] ~65-~65: The word ‘task’ is not correct in this context. Consider using the plural form, adding a determiner like ‘the’ or ‘a’, or adding a preposition like ‘at’ or ‘in’.
Context: ... - Accepted naming formats are using task type as prefix, forward slash ...
(BE_VBG_NN)
[uncategorized] ~97-~97: Possible missing article found.
Context: ...e easier to read in various git tools. Footer should contain a closing reference to a...
(AI_HYDRA_LEO_MISSING_THE)
[uncategorized] ~98-~98: Possible missing comma found.
Context: ...hould contain a closing reference to an issue if any. - github: https://docs.github....
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~108-~108: In American English, abbreviations like “etc.” require a period.
Context: ...ccoli, npm) - chore: Updating tasks etc; no production code change - ci: Ch...
(ETC_PERIOD)
[misspelling] ~115-~115: This word is normally spelled as one.
Context: ... code (white-space, formatting, missing semi-colons, etc) - test: Adding missing tests ...
(EN_COMPOUNDS_SEMI_COLONS)
[style] ~115-~115: In American English, abbreviations like “etc.” require a period.
Context: ...space, formatting, missing semi-colons, etc) - test: Adding missing tests or co...
(ETC_PERIOD)
[uncategorized] ~123-~123: Possible missing article found.
Context: ...ix. #### Subject The subject contains succinct description of the change: - use the i...
(AI_HYDRA_LEO_MISSING_A)
[uncategorized] ~160-~160: Possible missing comma found.
Context: ...e header of the reverted commit. In the body it should say: `This reverts commit <ha...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~180-~180: Use “the” before the superlative.
Context: ...eve this change ``` - It is always a best practise to maintain checklist in ...
(THE_SUPERLATIVE)
[uncategorized] ~180-~180: Possible missing article found.
Context: ...t is always a best practise to maintain checklist in every PR to make sure everything is ...
(AI_HYDRA_LEO_MISSING_A)
[uncategorized] ~180-~180: Possible missing article found.
Context: ... submitted properly along with your PR. Example checklist can be as follows: ```te...
(AI_HYDRA_LEO_MISSING_AN)
[uncategorized] ~227-~227: Possible missing comma found.
Context: ...ranch. 10. If the reviewer(s) suggests changes then: - Make the required updates. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~231-~231: It appears that a pronoun is missing.
Context: ... to ensure tests are still passing. - Depends on the project: Rebase your branch and ...
(SENT_START_DEPENDS)
[uncategorized] ~243-~243: Possible missing comma found.
Context: ...ository: - Delete the remote branch on GitHub either through the GitHub web UI or you...
(AI_HYDRA_LEO_MISSING_COMMA)
🪛 markdownlint-cli2 (0.17.2)
coding-standards/git.md
47-47: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
48-48: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
49-49: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
52-52: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
53-53: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
56-56: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
57-57: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
58-58: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
58-58: Bare URL used
null
(MD034, no-bare-urls)
59-59: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
59-59: Bare URL used
null
(MD034, no-bare-urls)
62-62: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
63-63: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
64-64: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
65-65: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
66-66: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
67-67: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
100-100: Bare URL used
null
(MD034, no-bare-urls)
101-101: Bare URL used
null
(MD034, no-bare-urls)
229-229: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
230-230: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
231-231: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
🔇 Additional comments (1)
coding-standards/git.md (1)
238-238: Fix heading level for consistency.The heading "After your pull request is merged" should be at level 2 to maintain proper document hierarchy.
This issue was previously identified in the past review comments. Apply the suggested fix to maintain consistent heading levels throughout the document.
| - [Table of Contents](#table-of-contents) | ||
| - [1. Git Configuration](#1-git-configuration) | ||
| - [2. Repository Structure](#2-repository-structure) | ||
| - [Main/Master Branch](#mainmaster-branch) |
There was a problem hiding this comment.
Fix the table of contents link.
The link text Main/Master Branch contains a forward slash which creates an invalid anchor link. This will prevent users from navigating directly to this section.
Apply this diff to fix the link:
- - [Main/Master Branch](#mainmaster-branch)
+ - [Main/Master Branch](#main-master-branch)Additionally, update the corresponding section heading:
-### Main/Master Branch
+### Main-Master Branch📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [Main/Master Branch](#mainmaster-branch) | |
| @@ Table of Contents line (e.g., around line 14) @@ | |
| - - [Main/Master Branch](#mainmaster-branch) | |
| + - [Main/Master Branch](#main-master-branch) | |
| @@ Corresponding Section Header @@ | |
| -### Main/Master Branch | |
| +### Main-Master Branch |
Description
Update git document as per current company standards
Summary by CodeRabbit