Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Franboo105110dI'm inclined to agree with you. Frequent small scale commits of working complete code is the way to go. Makes rolling back a whole lot better as you're not gonna undo a huge chunk of work. Plus it makes for much more meaningful commit messages and all other sorts of good things.
However, sometimes a big, chunky commit is unavoidable and not necessarily bad. In my experience during the lifetime of a project commits become smaller and more focused as time goes on. But initially there can be a couple of hefty commits with a bunch of changes that implement big features from scratch. Not always bad as long as you know that you're doing it and why, I think.
Personally i like branches cause they allow best of both. You make small commits until a feature is finished and smoke tested then squash the history into one commit before merging to keep the main branch clean
Fast-Nop263210dI commit for whole features or whole bugfixes because I hate it when the history is littered with hundreds of stupid one line commits.
eeee222910dOf course, make small commits. But don't commits pieces of code like setters and getters. Instead, commit your workflow, one commit per step. For example:
1. Stub SomeClass
This commit contains stub methods, i.e., the interface of a class.
2. Stub SomeClassTest
This commit contains the test methods you will write for SomeClass.
3. Test SomeClass
This commit implements the tests. At this point they fail, but at least you now have tested the specification for SomeClass.
4. Implement SomeClass
Here is when you write SomeClass. All your tests turn green.
Of course, some of these steps might require many steps, refactoring, adding libraries, etc., but that's where branching comes in. All this work happens on a feature branch for SomeClass. Any smaller steps can be committed to smaller subbranches. When ready, they can be squash merged into the feature branch to create the 4 commits above. (1/2)
eeee222910dIn turn, when SomeClass + tests are ready, I'd squash merge them to a development branch.
Finally, when all features and bug fixes are ready to be released, they can be squash merged into master or some other production branch.
In this way you have the best of all worlds:
- There are huge (squash or regular) merge commits with entire releases, features or development steps on the longer-lived branches.
- There are tiny commits per nitty-gritty change, that can easily tell you where bugs have been introduced.
Using a system like GitHub really makes it easy to keep a pristine history with few commits (one per release is possible!), while a the individual PRs and their commits can be found as well.
In this way, the details cascade in and out of view when required!
So in conclusion: commit small workflow steps, but (squash or --no-ff) merge them away!
YADU18710dI branch, then do small commits there, then squash and merge once the feature is done back to master
monkeyboy7110dI make any number of commits of various sizes in my feature branch, but then I squash them all so I have one commit per issue when merging to master.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job