DEV Community

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

Posted on

What's your commit strategy in personal projects?

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 (21)

Collapse
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.

Collapse
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.

Collapse
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.

Collapse
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.

Collapse
dianawebdev profile image
Diana Author

This is an interesting approach, thanks for sharing!

Collapse
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!

Collapse
noprod profile image
NOPROD ☄️

Yolo with a little of gitmoji >> gitmoji.carloscuesta.me/

Collapse
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.

Collapse
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.

Collapse
dipsylala profile image
dipsylala

Just as disciplined as if I was at work. Frequent commits to a branch, with each branch referring to a JIRA that could be a bug/new feature, with appropriate stylecop/semistandard checks. Merge to main triggers a static analysis scan. My memory can get hazy 6 months down the line, so being able to refer to 'why' I did something can be useful.

Collapse
kahdev profile image
Kah

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.

Collapse
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.

Collapse
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.

Collapse
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.

Collapse
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..."

Collapse
dianawebdev profile image
Diana Author

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

Collapse
vlasales profile image
Vlastimil Pospichal

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

Collapse
graystrider profile image
GrayStrider

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

Collapse
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)

Collapse
nekofar profile image
Milad Nekofar

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

Collapse
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