feat: Branching Docs #1086
feat: Branching Docs #1086
Conversation
Added Branching Docs
WalkthroughThe changes in the pull request introduce a new section titled "Release Processes" in the Changes
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: 1
🧹 Outside diff range and nitpick comments (4)
README.md (4)
103-108: Improve document structure and add context.The heading hierarchy should start with h2 (
##) for better document structure. Also, consider adding a brief introduction explaining the purpose of these release processes.Apply this diff:
-### Main Branch +## Release Processes + +This document outlines our branching strategy for managing code releases and maintaining a stable codebase. + +### Main Branch🧰 Tools
🪛 Markdownlint
106-106: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
109-116: Improve clarity and conciseness of branch descriptions.The branch descriptions are technically accurate but could be more concise and clearer.
Apply these improvements:
### Release Branches -Each release branch is based off of `main` or the release branch before it. It is used to prepare and stabilize the code for a specific release version (e.g., `release/2.0.8`). +Each release branch is created from `main` or the previous release branch to prepare and stabilize code for a specific version (e.g., `release/2.0.8`). ### Feature Branches -Feature branches are longer-lived features or refactors expected to take additional time. They should be based off of the targeted feature release branch. +Long-lived branches for features or refactors that branch from their targeted release branch. -This structure allows code to flow **from `main` to release branches to feature branches**. +This structure establishes a clear flow: `main` → release branches → feature branches.🧰 Tools
🪛 LanguageTool
[style] ~110-~110: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...e Branches Each release branch is based off ofmainor the release branch before it....(EN_WORDINESS_PREMIUM_OFF_OF)
[grammar] ~112-~112: This phrase is duplicated. You should probably use “Feature Branches” only once.
Context: ...e version (e.g.,release/2.0.8). ### Feature Branches Feature branches are longer-lived features or refactors ...(PHRASE_REPETITION)
[style] ~113-~113: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...e additional time. They should be based off of the targeted feature release branch. T...(EN_WORDINESS_PREMIUM_OFF_OF)
117-120: Enhance diagram accessibility and context.The merge diagram would be more useful with proper alt text and a description of what it illustrates.
Apply this diff:
- + + +The diagram above illustrates how changes flow through our branching strategy, from main branch through release branches and into feature branches.
139-143: Improve clarity of exceptions section.The exceptions section could be clearer and more specific.
Apply this diff:
### Exceptions -There are certain times where this flow does not work as intended. For example: +There are certain situations when bypassing this flow is appropriate: + * Build scripts: These may need to be run off of the default main branch instead of feature or release branches. -* Read me updates: These are not required to be on a branch and can be committed directly to main. -* Bug fixes that can be OTA updated: These can be committed directly to main to perform an OTA update. +* Documentation updates: Changes to README and other documentation can be committed directly to main. +* OTA-compatible bug fixes: Critical fixes that can be deployed via over-the-air updates can be committed directly to main.🧰 Tools
🪛 LanguageTool
[style] ~140-~140: It might be better to use ‘times’ with the time-relative pronoun ‘when’. (Alternatively, use ‘in/on which’.)
Context: ... ``` ### Exceptions There are certain times where this flow does not work as intended. Fo...(WHEN_WHERE)
[style] ~141-~141: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...Build scripts: These may need to be run off of the default main branch instead of feat...(EN_WORDINESS_PREMIUM_OFF_OF)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
docs/image.pngis excluded by!**/*.png
📒 Files selected for processing (1)
- README.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
README.md
[style] ~110-~110: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...e Branches Each release branch is based off ofmainor the release branch before it....(EN_WORDINESS_PREMIUM_OFF_OF)
[grammar] ~112-~112: This phrase is duplicated. You should probably use “Feature Branches” only once.
Context: ...e version (e.g.,release/2.0.8). ### Feature Branches Feature branches are longer-lived features or refactors ...(PHRASE_REPETITION)
[style] ~113-~113: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...e additional time. They should be based off of the targeted feature release branch. T...(EN_WORDINESS_PREMIUM_OFF_OF)
[style] ~140-~140: It might be better to use ‘times’ with the time-relative pronoun ‘when’. (Alternatively, use ‘in/on which’.)
Context: ... ``` ### Exceptions There are certain times where this flow does not work as intended. Fo...(WHEN_WHERE)
[style] ~141-~141: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...Build scripts: These may need to be run off of the default main branch instead of feat...(EN_WORDINESS_PREMIUM_OFF_OF)
🪛 Markdownlint
README.md
106-106: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
| Assuming your branch is `feature/scw`, and your feature is targeted for release `2.1.0`, follow these steps to rebase: | ||
|
|
||
| 1. First, checkout the feature branch: | ||
| ```bash | ||
| git fetch origin | ||
| git branch feature/scw -D | ||
| git checkout feature/scw origin/feature/scw | ||
| ``` | ||
|
|
||
| 2. Then, rebase onto the targeted release branch: | ||
| ```bash | ||
| git pull origin/release/2.1.0 --rebase | ||
| git push origin feature/scw --force-with-lease | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Fix git commands and improve rebase instructions.
There are several technical issues in the git commands that need to be addressed:
- The
git pullcommand syntax is incorrect - The branch deletion step might be confusing
- Instructions are too specific to one example
Apply these corrections:
-Assuming your branch is `feature/scw`, and your feature is targeted for release `2.1.0`, follow these steps to rebase:
+To rebase your feature branch onto a release branch, follow these steps:
1. First, checkout the feature branch:
```bash
git fetch origin
- git branch feature/scw -D
- git checkout feature/scw origin/feature/scw
+ git checkout -B feature/<your-branch> origin/feature/<your-branch>
```
2. Then, rebase onto the targeted release branch:
```bash
- git pull origin/release/2.1.0 --rebase
- git push origin feature/scw --force-with-lease
+ git rebase origin/release/<version>
+ git push origin feature/<your-branch> --force-with-lease
```
Added Branching Docs
Summary by CodeRabbit