Branch Creation

Every issue you create must have its own branch. Branching keeps work isolated, prevents merge conflicts, and makes pull requests (PRs) easy to review.

This guide explains the required naming conventions, how to create your branch, and how to keep it up to date throughout your sprint.

---

🎯 Purpose of This Step

Branching allows multiple developers to work in the same repository without interfering with each other’s work.
Your branch should always:

• Be tied to a single issue
• Contain a single coherent piece of work
• Be created from the correct base branch (usually develop or main)

---

🌱 Branch Naming Convention

Branch names should follow the format:

Use the same type categories used in issue creation:

• feature
• bug
• refactor
• experiment
• documentation
• chore

Examples:

• feature/add-login-form
• bug/fix-mobile-footer
• refactor/auth-service-cleanup
• documentation/update-api-readme

Avoid long names or spaces — keep branch names short, lowercase, and dash-separated.

---

🧑‍💻 How To Create a Branch (Required Workflow)

extensive documentation can be found on github docs

💡 Best Practices

• Create your branch immediately after creating your issue.
• Keep branch names short, lowercase, and easy to understand.
• Only work on one issue per branch.
• Pull from the base branch (develop or main) often to stay up to date.
• Commit small, incremental changes to make your PR easier to review.

---

⚠️ Common Mistakes to Avoid

Mistake	Why It Matters
Creating a branch before pulling updates	Leads to merge conflicts later
Working directly on main or develop	Breaks workflow and risks overwriting shared code
Naming branches inconsistently	Makes PRs difficult to track or understand
Including multiple features in a single branch	Leads to large, slow-to-review pull requests

---

🔗 Next Step

➡️ Proceed to: [Pull Requests & Draft Pull Requests](Pull Requests & Draft Pull Requests)