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.
Top comments (21)
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.
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!
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.
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.
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!
Yolo with a little of gitmoji >> gitmoji.carloscuesta.me/
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.
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.
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.
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.
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.
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
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.
Always write your code and commit messages as if the person who takes over your project is a maniac psychopath who knows your address.