Simple Git Flow

Introduction

This post is a run through of how you can work on a frontend project with Git and how you can safely store your code and collaborate with your team. This post uses git as the version control, and GitHub as our repository host — you should be familiar with both.

Branches

Branch	Purpose	Stability
main	Holding branch before deployment	Stable
feature-branch	This branch is being actively worked on and tested	Unstable
staging	“Production” environment which can be accessed by the internal team	Stable-ish
production	Production environment which can be fully accessed by external customers	Stable

How we work

Utilising various tools like PR deployments and CI we can avoid having multiple branches for multiple environments. Our way allows us to streamline our development and collaboration. Below is a diagram of a basic workflow when you come to build out a feature.

Dos

1. For your feature branch, every day (or so), you should be running git pull --rebase main to ensure you have the latest changes on your feature branch
2. Every new feature you work on, you should create a new branch which should be the ticket name from Linear
3. Commit messages should follow this convention
4. You should follow fill out the PR template with every PR that you open

Don’ts

1. Don’t hold up work by not committing a local branch to a remote branch
2. Don’t push work directly to main
3. Don’t commit application secrets or passwords
4. Don’t commit large media files (compress and resize where possible)
5. Don’t work on multiple features on one branch
6. Don’t open multiple pull requests for one feature

Helpers

1. Git Pretty — For a better visualisation of logging commits
2. What did I work on yesterday? — An alias to quickly show what you worked on the day before
3. Github Desktop — It is not a must you have to work on the terminal