/
Git

Git

Owned by Sanojan Thiyagaraja
Last updated: Jun 14, 2022 by Peter Derias
2 min read

Our main branch for both the frontend and backend team is dev.

Branch naming

Frontend

  • Start with your name, initials of the page that is worked on (term planner = ‘tp’, course selector = ‘cs’, progression checker = ‘pc', degree wizard = 'dw’ , then the <ticket number>- <description of the ticket>. Each of these sections is separated by a forward slash. Format is as such <dev_name>/<epic_shortcode>/<ticket_number>-<ticket-summary>

  • E.g. gabriel/cs/CF-123-integrate-sidebar-with-backend

  • NOTE: We dont strictly enforce the branch naming convention BUT you should atleats have the ticket number in the branch name.

Backend:

  • Use the following format: ${your_name}/${ticket}-${describe_ticket}

  • E.g. peter/CIRCLES-262-integrate-core-courses

Note: the code for the backend is a little bloated. try to remove more LOC than you add. That means that when adding a feature, try to find some bloated code in the same area and remove it. this isnt a strict requirement for a PR, just something to keep in mind. Also, this is not an invitation to code golf. This is to make our code more maintainable.

Pull requests

Your pull requests (PR’s) will merge into the dev branch. The title of the PR should include the ticket number and description e.g. CF-96: Integrate sidebar with backend.

Merging

The owner of the PR should also be the one that hits merge.

Also, when you squash your changes to pull, you should use Conventional Commits .

When you press the squash or auto-merge button, you can decide what to fill in the commit message. There, you would fill in the box based on the style of conventional commits.

so an example of this is: - i had to redo the redux store because i implemented marks

feat!: marks entry created a marks entry modal which successfully sends the marks data to the backend and checks that GRADE clauses can be met. BREAKING CHANGE: messed up the redux-store to make this happen

- I implemented sign in with google and migrated user handling to the backend

feat!: allow for users to sign in i did this by making bla bla database and stuff BREAKING CHANGE: fucked up the FE because redux goes bye bye - so the user data is lost again (hopefully for the final time)

notice that the headline definitions are user-focused, and the longer descriptions are developer focused. The longer stuff is usually the info you want to convey to the FE about your change, if anything. another example that isnt a breaking change:

feat(data): fixed isAccurate errors for ARTS i made ARTSFixes.py to do this.

also, notice that i offer the place i changed stuff if it is limited to one place^

Related content

UNSW CSESoc