2.3 KiB
2.3 KiB
description, alwaysOn, always_on, glob
| description | alwaysOn | always_on | glob |
|---|---|---|---|
| Project workflow rules, GitHub flow, and TODO.md tracking. | true | true | * |
Git Feature Branch Workflow
This project strictly follows the Git Feature Branch Workflow (as defined by Atlassian).
The core idea is that all feature development should take place in a dedicated branch instead of the main branch.
1. Development Workflow
- Never Commit to Main: Direct commits to
mainare strictly prohibited.mainmust always be stable and deployable. - Branch Creation: Create a descriptive branch from the latest
mainstate (e.g.,feature/animated-menu-itemsorissue-#1061):git checkout main && git pull origin main && git checkout -b feature/your-feature-name - Atomic Commits: Make small, logical, and self-contained commits to your feature branch.
- 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. - Merge & Close: Once approved, the feature branch is merged into
mainand then deleted. (You can use theclose_featureskill 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:
- Fetch Latest Main: Update your local repository's main branch:
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].