42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
---
|
|
description: Project workflow rules, GitHub flow, and TODO.md tracking.
|
|
alwaysOn: true
|
|
always_on: true
|
|
glob: "*"
|
|
---
|
|
## Git Feature Branch Workflow
|
|
|
|
This project strictly follows the **Git Feature Branch Workflow** (as defined by [Atlassian](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)).
|
|
The core idea is that all feature development should take place in a dedicated branch instead of the `main` branch.
|
|
|
|
### 1. Development Workflow
|
|
1. **Never Commit to Main:** Direct commits to `main` are strictly prohibited. `main` must always be stable and deployable.
|
|
2. **Branch Creation:** Create a descriptive branch from the latest `main` state (e.g., `feature/animated-menu-items` or `issue-#1061`):
|
|
`git checkout main && git pull origin main && git checkout -b feature/your-feature-name`
|
|
3. **Atomic Commits:** Make small, logical, and self-contained commits to your feature branch.
|
|
4. **Push & Pull Request:** Push the feature branch to the remote repository and open a Pull Request (PR) against `main`. PRs act as a forum for discussing the feature and performing code reviews before it is merged.
|
|
5. **Merge & Close:** Once approved, the feature branch is merged into `main` and then deleted. (You can use the `close_feature` skill for this).
|
|
|
|
### 2. Merge Conflict Policy
|
|
When multiple features are developed simultaneously, `main` might advance before your PR is merged, causing a merge conflict. **The author of the pending PR is solely responsible for resolving conflicts.**
|
|
|
|
#### Resolution Procedure:
|
|
Never force-push blindly or overwrite other developers' work without understanding it. Follow these exact steps to resolve a conflict:
|
|
|
|
1. **Fetch Latest Main:** Update your local repository's main branch:
|
|
```bash
|
|
git checkout main
|
|
git pull origin main
|
|
|
|
### 3. Documentation Update
|
|
|
|
.md Files die nichts an der Integrität oder Impact der Codebase beiwirken sollen als einfacher Commit in Main behandelt werden.
|
|
|
|
## Project Management
|
|
|
|
- The Current Development Progress is tracked and marked down and always updated in the File `TODO.md`
|
|
|
|
## Knowledge Management
|
|
|
|
- Every time you learn something new or worth mentioning about the project (e.g., architecture details, aesthetic conventions, logic workflows), you MUST document it.
|
|
- If it is not already recorded in the project's brain file, you must add it to `@[.agents/brain.md]`. |