Software Engineering Essentials is a series of blog posts designed to help you get started with a wide variety of software engineering topics. This post was originally part of my Go-Twitter project, a project-based curriculum designed to take someone from “zero” to “competent” in the world of software engineering.

All writing for this post is licensed under CC-BY-4.0, while all code is licensed under the MIT license.

GitLab

Branch Etiquette

Git makes working in groups much easier than manually copying and pasting code together from multiple sources. A centralized Git hosting service can make it even easier. Most of the time when multiple people work on a project, changes are committed to feature-specific branches. These can be bug-fixes, new features, refactors, or anything else. The important thing to keep in mind is to keep your changes organized in the proper branches.

If you’re working on a bug-fix on a branch named front-page-css-bugfix, don’t pollute that branch with unnecessary changes like fixing test cases in an unrelated function. The changes in a branch should correspond to that branch. If you really want to do that work and save it somewhere, feel free to create a new branch. Branches are free and easy to use, feel free to make new ones as you need.

Merge Requests

Merge Requests (or Pull Requests in GitHub lingo) are a mechanism in most Git hosting services designed to make it easier to handle merging in new changes. While Git has a lot of tools for managing changes and merges, the web interface is a bit easier to get started with for newcomers.

More important than the change itself is the Code Review process that merge requests assist with. Chances are, your merge request won’t be accepted immediately and without question. Most of the time, we have something to fix or something to change. The merge request view allows other team members to comment on your diff and even highlight individual lines or blocks of changes to leave comments. If you’ve ever used the “Track Changes” feature of Microsoft Office product, you’ll be well-acquainted with this interface.

When a merge request is accepted, your commits in the merge request will be applied to the branch your request targets (usually the main development branch). Then, whenever people fetch and pull changes, your commits will be pulled down to their local repositories. This keeps everyone in lock-step with each other while you all work on the same codebase.

Your old branches should be deleted once merged. This isn’t a technical requirement, it just keeps things clean.

Protecting Branches

Because the main development branch is used for collaboration and keeping everyone on the project on the same page, you usually don’t want to commit changes directly to it. Instead, you commit changes to the main development branch through merge requests. This ensures that the commits people are adding are reviewed and communicated before they are added to the main branch.

Most Git hosting services have a feature that will allow you to protect certain branches. Protecting a branch can prevent things like deletion and/or directly pushing changes onto that branch. Instead changes are added in through merge requests.