My Git Management Strategy
By: Matthew Weeks
Tags: Software Development, Programming, Productivity, Git, Web Development

Every new software project requires a version control strategy that suits a variety of needs:

A locked down master branch that is always shippable to production

Easy to follow for all development team members

Creates a clean history that makes it easy to understand what changes occurred

As a bonus, the following strategy also enables effective code review, and the ability to create automated releases, versioning, and testing.

First, What branches are important?

Master

Note: Keeping this as “master” for historical context, but future projects will use “main”

Your master branch is your source of truth for the current state of the application.

Any code deployed to master can (and should) be deployed to some form of production environment.

Changes being merged to master should already have undergone any checks or guards that your team establishes for code to be considered “done”. This could include unit testing coverage, integration testing, manual testing, QA approval, security check, and code reviews.

To

Develop

If your team builds products in larger release candidates, this branch would be where you merge and integrate that next version. This branch is inherently more volatile than master, but it should still represent a functioning version of the site.

If your team is disciplined enough to only create functioning, isolated features, you might not actually need a develop branch. Pull requests might even be made directly to master, integrated, and tested there, and then be deployed as soon as it is approved — however, that is an idea for a more involved article on trunk-based development.

Feature branches

When we build functionality or changes to the codebase, we branch off of the current develop branch, and make our changes against it.

When changes are ready to deploy, we will open a pull request against develop and go through the necessary checks, such as a code review, automated testing, linting, and QA review. With proper tooling, these changes can be integrated and deployed to a production-like environment, where it can be tested alongside existing code.

These branches can be named however your team prefers.

I personally follow the convention of prefixing each branch with its type of change:

feature/

chore/

fix/

improvement/

Followed by a brief description of the actual change.

Example: feature/header-logo, fix/blog-feed-not-loading, chore/upgrade-node-packages, or docs/deployment-process

Next, how do we actually make changes?

First, branch off of develop

git checkout develop

git checkout -b feature/blog-reel

Now we have our new feature branch!

Next, let’s make some commits

When making commits, it is good to have a standard, but some general best rules:

Each commit is a functioning change that another developer can pull into other branches safely

Affects a specific enough scope that it can be easily reviewed and understood.

Describes what occurred at a glance, but includes any necessary description.

As with all naming, do what you prefer, as long as you have a standard.

I personally follow Semantic Commits, which I may write about later.

An abbreviated description:

[type]([scope]): [description of change] [Explanation of changes] [#ISSUE NUMBER]

This can amount to something like:

feat(blog): Add descriptions to blog reel - Add descriptions to GraphQL Fragments and queries

- Add description to BlogReelItem container

- Add descriptions to test fixtures

- Update tests [#3]

Depending on your requirements, you can probably just get along with the first line. Just be sure to make the reader aware of what this change will do to the software!

When the code is done, we create our pull request!

…But first, we rebase!

git rebase develop

Okay, now open that pull request

Inside of your pull request, you’re going to have to add a title and description. It is good to have a standard way of writing these. If you’re interested in really standardizing the way you make PRs, consider github-templates.

From here, someone on your team should give your code a code review. If you are the only one, wait a day, and then try to re-read the code. Make comments and write out questions wherever something is difficult to read or understand, and tag if there is a significant issue. This is the same process you’ll follow on code reviews for others as well!