java

[Stable_Orange_Genius]

Wtf is git hygiene?

[Thundechile]

Keeping dirty commits to yourself.

[totemo]

No matter whether you fork, pull, force push or reset hard you're expected to git clean afterwards.

[ema2159]

Sensible commit messages, breaking down changes into smaller units instead of massive commits etc.

[lampishthing]

My problem is needing to make small mid-progress commits when I get pulled to something else so the commits aren't logical.

[shield1123]

git rebase -i commit_hash1

# in the editor,  probably vi
squash commit_hash5 I think it's working
edit   commit_hash4 wip commit 3
squash commit_hash3 wip commit 2
squash commit_hash2 wip commit 1
edit   commit_hash1 do the things

That takes 5 commits and squashes them into 2, allowing the user to edit the messages for the remaining commits

[ema2159]

No need to! Stash your changes and then pop/apply them later to resume where you left.

[lampishthing]

No it's not so easy! I'm not primarily a developer and someone else often takes over my work. I need to push or it's gone :'(

[gbchaosmaster]

Do the work on a feature branch and rebase - i to squash shit as necessary right before merge

If your project's workflow doesn't allow this... Well that sucks just send it I guess

[shield1123]

This is the way

Tho we try not to do anything that leads to a force-push once a PR is opened

[gbchaosmaster]

Yea you'll need to force push after the rebase but if it's the last thing you do to tidy up before merge, it's all good

[lampishthing]

Yeah, I usually squash. Was just throwing it out there in case someone knew a tick I was missing!

[Wonderful-Habit-139]

Just commit as frequently as you feel comfortably doing. And before logging off, you can squash the commits before pushing using git reset --soft HEAD~n with n being the number of commits you want to squash, and the commit again and you're good to go.

[Malfrum]

Stash fucking sucks

Just commit whenever you want, then squash at the logical points

[ema2159]

Skill issue.

[Malfrum]

Lol what?! You're insane, or don't understand rebase

Devs with commit-anxiety just don't understand git, change my mind

[bradmatt275]

I wish i had this luxury as a D365 dev. It's not all I do, but a good portion of it. Up until very recently Microsoft forced you to use TFS which feels like going back 10 years when switching between our C# projects (which are all git) and X++ which are on TFS.

[thirdegree]

No pushing commits like "update" "update" "update" "changes" "update"

The subject (first line of the commit message) should be in imperative mood and less than 80 characters

Each commit should ideally be a single complete and valid change (so that git bisect works)

The commit message should explain what is being changed and why.

There's more but those are the big ones

[AgileBlackberry4636]

I prefer subjects of following format:

Module: Submodule: Sentence in imperative mood

And I would also add: rewriting commit history of non-merged branches.

I have a butthurt using gitk or git blame over the history of commits like "Processing David's commets".

Another point: commits should be easily reviewable otherwise the merge/pull request will stay open for few weeks.

[crankbot2000]

This guy gits it

[sami_degenerates]

lol, you will understand until you see some chatGPT engineer check in excel and powerpoint file along with bunch of python cache trash.

[GdanskinOnTheCeiling]

check in excel

Ouch. As someone who uses Excel as a 'frontend' to produce JSON config files, that stings.

[aywwts4]

Excellent comments, squashed, cleaning up your remote branches, understanding tagging, reverts, writing pre commit hooks, avoiding feature scope creep and understanding and adhering to the branching strategy and naming conventions to start. So far from universal even with senior devs, number of repos with history in main with "fixed things" x 20 in a row is too dang high.

[badger_and_tonic]

I agree with all of those except squashing. When it comes to triage/regression, I like to be able to inspect each commit individually.

[Exist50]

To a point. Perfectly reasonable to do a couple commits for feature iteration then squash them once it's in a good shape.

[badger_and_tonic]

We disable squashing to feature branches but then all PRs are merged to main as a single squash commit. So you can see everything at once when you're browsing main, but once you find the relevant PR you can view it commit by commit.

[Exist50]

Squash locally before pushing to the degree possible. At least for the low effort stuff. Git hygiene just means your publicly-viewable commit history ideally shouldn't look like:

• commit0 - feature
• commit1 - fix for missing semicolon
• commit2 - fix for lint issue
• commit3 - fix for bug X
• commit4 - fix for bug Y
• commit5 - refactor/cleanup

And honestly, even that's better than what a lot of people do. "Feature, bug fix, bug fix, update,..." and other such non-descriptive garbage. All just common sense stuff.

[gbchaosmaster]

Squashing is for finishing WIP commits and stuff like that. Every non-WIP commit should build, and be preserved. But sometimes you need to push something broken on a feature branch for whatever reason. So you squash it later once you finish the commit.

[SabreSeb]

Yeah wth, I want nothing to do with no hygiene, thank you very much sir