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.
Latest comments (21)
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.
Always write your code and commit messages as if the person who takes over your project is a maniac psychopath who knows your address.
Whenever you make a substantial, potentially breaking change - commit. It only takes a second, anyway.
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.
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)
For small projects, I have a
master
+ features branches, for others, a stablemaster,
a "less" stabledevelop
+ 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.
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.
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.
Commit small, commit often. More commits for every feature. I like git diff.
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.
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.
This is an interesting approach, thanks for sharing!
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!
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
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.
git status ->
Oh, I changed stuff here 4 months ago.. I wonder what that was about... oh well
git commit -m "Stuff..."
This happens to me even if I left this code sitting for like two days. :D