DEV Community

Cover image for What's your commit strategy in personal projects?

What's your commit strategy in personal projects?

dianawebdev profile image Diana ・1 min read

One commit for every feature, regardless how long you'll work on it? One commit a day, regardless which features or bugfixes you worked on?

Or do you go full git-style? Particular Branches for dev and release, a new branch for every feature, one commit for every little part of the feature?
Do you even have your own ticket systems or user stories?

What's your workflow with versioning in personal projects?
Looking forward to your comments and thoughts.

Discussion (20)

Editor guide
elmuerte profile image
Michiel Hendriks

As somebody who believes in (real) continuous integration: frequent commit and merge to mainline. Once released, patches go into release branches and from there, on to the mainline.

Martin Fowler wrote an excellent article on various branching patterns.

darthbob88 profile image
Raymond Price

One branch for release, with feature branches that get squashed down so I can have a single commit for each feature I add. Individual commits are just "WIP" and "HAIL SATAN", because the unit of change is the PR.

dianawebdev profile image
Diana Author

This is an interesting approach, thanks for sharing!

dianawebdev profile image
Diana Author

As soon as a project is "live" (whatever this means), I'll have a release/main branch and a dev branch. I create a new branch for every bigger feature and try to commit coherent parts of the code as often as possible.
Bug fixes are done in the dev-branch, except for complicated stuff, then theres a /bug/OHNOEZ branch.

If I just get into something new and try some stuff, everything is a bit messier, but basically that's it for me.

florianjisopp profile image
Florian J. Isopp

I commit when "something" encapsulated, rather small than big, is done. Programming should be like a series of experiments. So it must be cheap (fast and easy) to try that experiment, and cheap to recover.

Very recently it, I tried the "Projects" feature of github with the default Kanban board.

That's very easy and a simple combination with the git repo. Once again, keep everything about programming/experimenting simple. And github offers a lot of it. So it is worth a try, especially for personal projects.

noprod profile image

Yolo with a little of gitmoji >>

ptrjsn profile image
Peter Johnson

I've generally been using Feature Branch Workflow. One of the main points of personal projects for me is getting used to technologies I don't otherwise use every day, or using them in a way I'm not used to, & Git is part of that, so sometimes I'll use multiple feature branches simultaneously & rebase, & create pull requests instead of merging directly, playing around with different workflows. At the same time, I find my regular development best practices apply, like committing at least daily; I treat my computer like it could die at any moment, save & back up frequently (pushing to GitHub to back up some code), & it only takes losing a bunch of work once to give you a lot of motivation to prevent it from ever happening again!

mtancoigne profile image
Manuel Tancoigne

For small projects, I have a master + features branches, for others, a stable master, a "less" stable develop + features branches.

In every cases, small commits and regular interactive rebases in feature branches are my way to keep it clean.

Oh, and no merge commits, only fast-forward merges.

dsebastien profile image
Sébastien D.

For small personal projects, I make small/focused commits (usually don't like to mix things up), but I don't setup "complicated things" like conventional commits, release automation & such. I just KISS.

For any larger project (subjective indeed), or any collaborative project, then I set those up and enforce conventional commits, changelog generation, etc. At Git's level, I use forks, feature branches and PRs.

I usually follow Gitlab's flow, which is (IMHO) the simplest and most effective collaboration model. Clean, simple, no extraneous branches and a great level of control / visibility.

giorgosk profile image
Giorgos Kontopoulos 👀

It is nice to use best practices even on your own or small projects. I usually commit smaller commits (atomic) that can be described in one commit message. If the commit message gets too long perhaps needs a smaller commit and it helps at a latter time when you are wondering what you have done.

For personal projects I usually don't create feature branches but commit directly on main as the decision to merge is usually my own.

kahdev profile image

I break down the changes into distinct steps and commit at each step. I think of it like showing the working out in a maths problem (each step is a commit). For example, if a feature I am working on requires a refactor, I would commit the refactor separate from implementing the feature (as if they were two different steps).

I don't use branches on my own personal projects. I find that I work on just one thing at a time anyway, so haven't found them useful for personal projects.

vlasales profile image
Vlastimil Pospichal

Commit small, commit often. More commits for every feature. I like git diff.

kimfransman profile image
Kim Fransman

git status ->
Oh, I changed stuff here 4 months ago.. I wonder what that was about... oh well
git commit -m "Stuff..."

dianawebdev profile image
Diana Author

This happens to me even if I left this code sitting for like two days. :D

fluffynuts profile image
Davyd McColl

Commit small, commit often. We use feature branches simply because it facilitates easier and neater code review, but I'm a fan of "work on mainline" for faster iteration, especially on smaller teams.

mendoza profile image
David Mendoza (He/Him)

Personally I love the commit a day, but sometimes i think people don't know that a commit can have multiple lines... so that's sometimes weird for people hahaha

graystrider profile image

Whenever you make a substantial, potentially breaking change - commit. It only takes a second, anyway.

andrius profile image
Andrius Kairiukstis

I try to follow up git-flow technique, but I do not commit often (I love to commit quite big chunks of the meaningful stuff)

nekofar profile image
Milad Nekofar

Mostly the GitFlow workflow and recently combined with Conventional Commits specification.

gergelypolonkai profile image
Gergely Polonkai

Always write your code and commit messages as if the person who takes over your project is a maniac psychopath who knows your address.