Development using Git branches

Git branches

A branch refers to a version/snapshot of the application's source code.

The Main branch (also known as master) is the branch where, according to convention, the latest version of a properly working and thoroughly tested application should reside. Code is never pushed directly to it, and protective measures are used when implementing changes.

Before starting to write code, a copy is usually created from the main branch, called a feature branch. This acts as a sandbox for the developer, where they can develop new features, remove old functionality, or test solutions without affecting the functionality of the application built on the code in the main branch, which may currently be in use by real-world clients.

Often, an additional development branch is added between the main and feature branches for additional security purposes. Changes are consolidated in this branch before being added to the main/master branch for testing together to ensure that the code reaching it is truly foolproof.

Managing Branches in Gitlab

Branches can be viewed and managed in Gitlab here:

A new branch can be created from here:

To fetch it to your local computer and start writing code, it should be fetched and checked out

It's a good practice to create a separate feature branch for each issue/ticket, which helps ensure that the functionality being changed at once doesn't become too large (difficult to test, increased risk of conflicts and errors, more difficult to debug and revert changes).

Merging

Once the functionality scoped by the issue is completed and tested in the feature branch, it's time to merge the written code into the main or development branch.

Merging is the process of adding the changes from one branch to a target branch. Usually, after pushing the feature branch to git, a merge request should be created before actually merging the code, where all changes can be seen before merging, and a person (team member) can be assigned to review the changes, also known as code review.

No merging to the main branch should occur without a code review!

Active, already merged, and closed merge requests can be seen here.

By opening it, the code reviewer should go over the changes and ensure the quality of the code: whether the code works as needed, whether the solution is reasonable, or if it could be improved in any way.

It's important to note that if an error occurs, the responsibility falls on the code reviewer as much as on the code writer!

Sometimes it's useful to pull this branch to your computer to better navigate and manage the overall picture and, for visible functionality, to even run the application (a game in this project) yourself and try it out. NB! When checking out another branch, active (uncommitted) changes in your current branch should be committed or shelved, as otherwise they will move along.

If the reviewer is satisfied that the newly implemented code is of high quality and functional, they can approve the merge request. Otherwise, they can leave line-by-line suggestions right there or contact a teammate who, upon receiving correct feedback, would fix them and push them to gitlab again (there's no need to create a new merge request for this, they will be shown immediately after the push).

Merge Conflicts

When making a merge request, git may detect merge conflicts.

This happens when the same code is modified in multiple different branches (for example, two individuals both create their feature branches from main at the same time, and the first person modifies method A in their branch and merges it, and the second person also modifies the same lines in their branch and tries to merge before merging the changes to main) and Git doesn't know which one is correct. Therefore, these need to be resolved by showing git which changes to take.