DEV Community

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

What's your commit strategy in personal projects?

Diana on December 05, 2020

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

This is an interesting approach, thanks for sharing!

Collapse
 
dianawebdev profile image
Diana

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
 
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
NOPR9D ☄️

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

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

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

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.