For now when dealing with Git/GitHub, managing own repos I stick to:
make plenty relatively small commits.
Partly because of learning: I wanna each commit be a remainder about some CSS prop or whatever this commit was about.
But also because I am thinking: ‘Some day some HR guy will take a quick look at contribution panel, and it will be all nice and green. That would come in handy.’ But that feels a little like cheating Any thoughts about that?
This is a common recommended practice. Smaller more direct commits give you increased flexibility and clarity down the line. There is a point where too many commits becomes too redundant, so there is a fine line though.
A github’s contributor graph, the one with green tiles is usually only 1 metric referenced by recruiters who check github. Another is the project’s themselves. Relying purely on being active on github wont be too useful if your only active on simpler/basic projects with “spammy commits”. It would probably help, but I don’t see it as disingenuous if that is how your work, but I also see it as only 1 metric among many that a recruiter would check if they go to your github.
Having a portfolio with solid looking projects would still probably be the first-stop of any would be recruiter (among official channels like your linkedIn and resume)
I would not worry about keeping the github loaded up with green - I think that gets overemphasized. But the opposite - one mega commit for every 10k lines of code is bad too. Make timely, smart commits.
I think commits should be based around tasks - changing the login UI, refactoring the sound API, fixing the phone number filtering bug, etc. That is kind of how it will be when you get a job, discreet little jobs. If I’m working on a large job, I tend to mentally break it into smaller chunks and those may be their own commits.
I may make tiny commits while I’m working on something, but I’ll usually rebase those into one commit.
So yeah, make frequent commits, but don’t go crazy.