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. 😔

Maybe 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.

Odd, we commit multiple times and only pay attention to pull requests

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.

@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.

@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.

There is nothing wrong with small and frequent commits.

@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.

@AlmondSauce <---- what he said