My personal Git flow

Over the years and across many projects, I’ve refined a way of working with Git that makes my life easier.

It’s probably not perfect. But it works perfectly for me, and it helps teammates who are less comfortable with Git avoid a lot of headaches. So I’m sharing it here in case it helps someone else.

The basics

I always start from the main branch. I create a feature branch with a clear name:

git checkout -b feat/my-feature

One single commit

I make one single commit per branch, with a clear and explicit message.

If I need to fix something (a missing file, PR feedback, etc.), I don’t create a second commit. I amend the existing one:

git add .
git commit --amend --no-edit

Then I force push

I force push to keep the history clean and linear:

git push -f

Always rebase, never merge

If main has moved in the meantime, I never merge. I rebase my branch on top of it:

git fetch origin
git rebase origin/main

Why no merge? Because:

  • it avoids "Merge branch 'main' into…" commits that pollute the history

  • it keeps the history linear and much easier to follow

  • it drastically reduces last-minute conflicts

The result

  • One branch = one commit = one clean diff

  • The history stays simple and under control

  • PRs are easy to read and quick to merge

  • Conflicts are caught early and isolated

In summary

I’m not saying this is the perfect method. But it’s worked very well for me for years, and proven itself on many projects.

If you often struggle with conflicts or unreadable Git history, it might be worth trying.