Simple Git Flow
24 December, 2022
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
- 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 - Every new feature you work on, you should create a new branch which should be the ticket name from Linear
- Commit messages should follow this convention
- You should follow fill out the PR template with every PR that you open
Don’ts
- Don’t hold up work by not committing a local branch to a remote branch
- Don’t push work directly to
main
- Don’t commit application secrets or passwords
- Don’t commit large media files (compress and resize where possible)
- Don’t work on multiple features on one branch
- Don’t open multiple pull requests for one feature
Helpers
- Git Pretty — For a better visualisation of logging commits
- What did I work on yesterday? — An alias to quickly show what you worked on the day before
- Github Desktop — It is not a must you have to work on the terminal