Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
endroll284yMaybe he reviews each commit. If all your commit messages are "WIP" then it will be a pain to review. Just squash related commits and put something helpful in the message before you push.
-
Honestly, no code review happens in our company, the seniors don't have much time for that. 😅 Even we don't follow TDD approach. Sadly, we merge our own created feature branch to 'dev' branch.
-
endroll284y@cypher-clown Then he's probably used to putting all changes in one big commit and is not used to seeing git utilized like how you do it. You're not doing anything wrong. That said, organizing your commits and putting helpful messages when you can could save you in the future. Happened to me plenty of times.
-
Crost41084y@cypher-clown this is a false economy where inevitably crap software is created, causing production issues or slow development, building and slowing the senior devs down even more over time. Makes no sense.
But you guys do you :) -
One concept per commit. Otherwise you end up with “Miscellaneous bug fixes” type of crap.
-
Parzi88334y@platypus listen, man, if i commit and it all works, then it works for literally no one else but me, there's gonna be 4 or 5 commits of trying desperately to fix it and then when I find the ONE BRACKET that no IDE or compiler saw was extra/missing in a 7000+ line file, i'm gonna push a "miscellaneous bug fix" commit. (I've actually done this, but the commit message was "ONE FUCKING SEMICOLON???". I may not be good at making "good" commit messages, but the suffering should be left on the record.)
-
Your team member is a rampaging moron.
Firstly he should be reviewing the branch, not each commit. Secondly, if he really has a problem with it then just squash and merge - it's standard practice in many cases anyway. Thirdly, commits should be as granular as possible to allow for easy bisecting later.
If it's really an issue then just rewrite your branch history to squash before review. But I wouldn't be putting up with crap like that, personally.
Is there a limitation of how much I can commit in git each day in a separate 'feature-branch'?
Cause, I had to explain to a team member (somewhat senior than me) why I committed 9 times in a single 8 hours task(s) (according to him where it was two separate tasks done in a single day).
When I said, I prefer to save my progress in a small commit (at least try my best to write meaningful commit)", I turned out to be a stupid team member. 😔
rant