Technológie

A Lean Git Workflow for Solo Developers

Posted on by VMe

Using GitLab with CI/CD and versioned releases? Here’s a simple, low-overhead workflow for solo developers: short-lived feature branches, a always-releasable master, annotated tags, consistent GitLab Release notes, and clean branch deletion after merge.

If you’re a solo developer, a full GitFlow setup (develop + master + release/*) is often more process than value. At the same time, you still want clean history, reliable versioning via tags, and consistent release notes you can trust.

This is a “lean” alternative: one stable master branch, short-lived feature branches, and shipping via tags + GitLab Releases.

1) Sync before you start

Fetch remote updates and clean up references (deleted branches, tags):

git switch master
git pull --rebase
git fetch origin --prune --tags

2) Create a feature branch

Do each change in its own branch:

git switch -c feature/<short-topic>

3) Work and push to GitLab

Commit your changes and push the branch:

git add -A
git commit -m "..."
git push -u origin feature/<short-topic>

4) Merge into master in GitLab

Create a Merge Request (MR) and use:

  • Squash merge (recommended: clean history)
  • enable Delete source branch (GitLab deletes the remote branch after merge)

After merge: update local and clean up

5) Update master and delete the local feature branch

After the MR is merged:

git switch master
git pull --rebase
git branch -d feature/<short-topic>      # use -D if it refuses (common after squash merge)
git fetch origin --prune

Note: with squash merges, Git may consider the local branch “not fully merged”, so -D is sometimes necessary.

Release cycle (tag + GitLab Release notes)

6) Tag master and push the tag

When master is ready to ship, create an annotated tag and push it:

git switch master
git pull --rebase
git tag -a vX.Y.Z -m "vX.Y.Z"
git push origin master
git push origin vX.Y.Z

Tip: Often you can skip git push origin master because the merge already updated master on GitLab—then you only push the tag.

7) Write the release notes in GitLab

In GitLab UI, go to:

Deploy → Releases → New release

Select tag vX.Y.Z and write your release description (highlights, fixes, any breaking changes, migration steps).

Why this is optimal for solo developers

  • Low overhead: no develop, no release/*
  • master stays always releasable
  • Tags + GitLab Releases provide a clear audit trail
  • Feature branches keep work isolated and the repo clean

One more thing

If you want your tags and release notes to stay consistent over time, adopt Semantic Versioning (what should count as MAJOR/MINOR/PATCH) and keep a curated CHANGELOG.md in the repo. The two best references are:

Žiadne súvisiace články.

, ,
VMe