beefyi

Rebase-based Git Workflow

guidesprogramminggitbeeps

My preferred Git workflow is rebase-based. Keep the feature branch current with main, then let the pull request merge as a fast-forward when possible.

git checkout <MAIN>
git pull --rebase
git checkout <FEATURE/BRANCH>
git rebase main

You can check locally if ff-only will work before merging:

git checkout <MAIN>
git merge --ff-only <FEATURE/BRANCH>

Then push the updated feature branch safely:

git push --force-with-lease

I like this because the project history stays simple. A pull request becomes a clean line of work instead of a pile of merge commits. If something goes wrong, rollback is easier because the commits are easier to reason about.

When a PR is squashed or kept as a tidy stack, each commit can be treated as a self-contained change. The result reads like one developer worked through the project in order, rather than several branches being stitched together after the fact.

Pair this with Conventional Commits and you get a solid setup: readable history, predictable commit messages, and PRs that are easier to review, squash, revert, or turn into changelog entries later.