Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
PerfectAsshole6944129dPersonally 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-Nop8915129dI commit for whole features or whole bugfixes because I hate it when the history is littered with hundreds of stupid one line commits.
eeee2463129dOf 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)
eeee2463129dIn 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!
YADU277129dI branch, then do small commits there, then squash and merge once the feature is done back to master
monkeyboy419129dI 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.
PerfectAsshole6944129d@DLMousey any idea on their reasoning?
Hello fellow ranter,
I just launched https://devzin.xyz/ (version 0.0.1).
I am gonna keep my faovrite rants there and this rant is one of them. Please let me know if you wanna remove it from there.
PS : I am willing to open it for anyone to use and welcome any kind of collab.
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