Introduction
As I started publishing my personal web app projects as part of my portfolio, I decided to create a Git workflow rule for personal development.
In this post, I’ll summarize the rules I came up with for my own projects.
Why I Decided to Set Git Rules
Up until now, I hadn’t often joined projects with well-defined Git workflows, and in my personal projects, I hadn’t really set any rules either.
But since I’m publishing repositories as portfolio pieces, branches and commit history will be visible too. That made me realize: I need a workflow that’s easy for others to understand and easy for me to manage.
My Workflow Rules
Here’s what I decided.
Branching
I’ll structure branches as follows:
- main: always stable and deployable
-
feature/*: for adding new features
- e.g.,
feature/login-page
- e.g.,
-
fix/*: for bug fixes
- e.g.,
fix/api-endpoint
- e.g.,
-
docs/*: for documentation updates
- e.g.,
docs/update-readme
- e.g.,
This is inspired by GitHub Flow.
There’s also Git Flow by Vincent Driessen, but that’s typically used in larger, long-term projects.
Commit Messages
I’ll write commit messages in English, following Conventional Commits.
Message Format
<type>: <short description>
Types I use
-
feat: add a new feature -
fix: bug fix -
docs: documentation only -
style: formatting (no code changes) -
refactor: refactoring -
chore: configs, dependencies, etc.
Examples
- feat: add weather API integration
- fix: correct date formatting issue
- docs: add system architecture diagram to README
- style: apply prettier formatting
- refactor: extract API call into separate module
- chore: update dependencies
Commit Timing
Here’s when I commit:
First commit:
After setting up the initial folder structure and dependencies (e.g., package.json).
Second commit:
Once the app has taken some shape.
After that:
Commit by feature or task unit.
This means there’s usually a gap between the first and second commit. That’s intentional: in the early stages I tend to experiment a lot with architecture and setup, and I don’t want those messy trial-and-error steps cluttering the history.
Summary
For my personal portfolio repositories, I decided to follow these rules:
- Branching: GitHub Flow style
- Commit messages: Conventional Commits + English
-
Commit timing:
- First commit: when the environment setup is ready
- Second commit: when the app has taken shape
- Afterwards: per task or feature
I’ll start with this workflow and adjust or expand it as needed.
If you have suggestions for even better Git practices, I’d love to hear them!
Top comments (0)