/
Branch Naming

Branch Naming

Our main branch is dev LOLOLOLOL

Branch naming

When naming branches, there are three segments to include, each providing another layer of context.
The general structure of a branch name is:

[prefix]/[scope]/[title]

Prefix

The first segment of the branch name is the main type of changes that the branch is making. 90% of branches will begin with a feat or a fix, meaning that they are either providing a new feature to the codebase, or fixing a bug. Immediately from the prefix, you can tell the purpose of the branch.

A rough list of prefixes to choose from are:

  • feat - The branch contains a new feature or new change for the code.

  • fix - The branch contains a fix for a bug or a series of bugs.

  • style - The branch is purely just for code style changes or something similar.

  • tests - The branch is purely for adding or changing tests

  • deps - The branch is upgrading a dependency (rare)

  • chore - This branch could be for other chore work, such as documentation or github action changes

This is best effort, if your branch does not fit under one of these categories, feel free to reach out for ideas or come up with something yourself!

If your branch is resolving a issue, it is very likely that the issue already has a label that correlates to one of these prefixes, so please use that!

Scope

The second segment of the branch name is code scope. This gives a rough overview of where the changes are being made, which helps categorize your branch and give further context.

A more precise list of what scopes you can use:

  • Frontend Scopes

    • cs - Course Selector changes

    • dw - Degree Wizard changes

    • gs - Graphical Selector changes

    • lp - Landing Page changes

    • tp - Term Planner changes

    • pc - Progression Checker changes

    • fe - Any other frontend changes, or multiple of above

  • Backend Scopes

    • user - User data related changes, including user data API routes

    • api - Non-User related API layer changes

    • db - Database layer changes (either mongodb or redis)

    • dp - Data scraping, parsing and processing changes

    • be - Any other backend changes, or multiple of above

  • Other scopes

    • other - Anything not mentioned above, maybe a docker change, etc…

    • all - Major changes to both backend and frontend

This is also best effort, and ideally you pick the most precise scope that encompasses the majority of your changes. (If you make one line change to backend, and 100 lines in graphical selector, it does not become an all scope, it remains as gs)

Again, if your task comes from the project board, this is likely already designated in the scope field

Title

Finally, your branch should finish with about 3-6 words separated by hyphens of its purpose is. This can also optionally start with the issue number if you would like, but it is not necessary. Given this, and the previous layers of context, I should be able to understand the entire goal of this branch and what it affects.

Some examples of good titles:

  • 331-migrate-userdata-to-backend

  • change-codeowners-for-2024-devsoc

  • 1128-create-reusable-notification-hook

Some examples of bad titles:

  • fix-bugs

  • remove-routes-in-api

  • unilectives (lucas )

Examples of it all together

  • feat/gs/add-circle-highlighting-on-hover

  • fix/db/pydantic-types-not-matching-mongo

  • feat/all/331-migrate-userdata-to-backend

Related content