I would add `git rebase -i`, beacause I usually develop on a local branch and rebase it to the updated one. With git things can get messy when you want do something outside of the basic stuff. What I hate the most is resolving 3 way merges.

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file!

I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit.

I do run `git diff` first to see what I've changed, and if the diff has unrelated changes in different files I'll usually break it up into separate commits.

Decent introductory list, though. It won't surprise you that I think diff should be learned immediately; whether or not you need rebase depends on the conventions of the codebase, and if someone can learn it later they should, it can get tricky.

True, an error. Corrected.

I’m interested in how many people double check their changes before committing as I’ve done this since the days of sourcesafe, and a decent number of bugs I’ve seen are people just not checking what they committed (some stray change got in that they never intended)

Yes! I find that if I don't comment my PRs, my coworkers avoid them. But then in commenting them, I find quite a few ... not always errors, but cleanups at least.

Odd that you put switch on this list but not restore. Undoing changes is pretty important.

> 8. git branch [branchname] -D : delete branch if not tracked

Dangerous advice there. Use the lower-case '-d' option. It'll tell you that you maybe don't want to delete the branch when it has unmerged commits.

If you really want to delete the branch then, the output of `git branch -d` tells you this option.

You're missing out. You need rebase and cherry-pick. Merging sucks.

Merging rocks! Never had an issue with merging and it’s less work. I’d only rebase if there is a “story” I want to tell in the commit history, that would be otherwise lost. This is rare, probably if someone else did some major refactor or move around

Merging makes life harder for others, and easier for you. Rebasing does the opposite, but has other benefits.

It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others.

If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it done because usually master is linked to CI and the idea is is every commit to master should be a valid build.

Master or any branch you're aiming to integrate into.

Squashing everything is bad because it makes code review and backports harder. Maybe you don't care about backports, but if you care about code reviews...

We code review unsquashed branches.

Honestly I just diff the whole thing from where they branched to the tip anyway I rarely find the individual commits useful as there is usually a process of their discovery in that with backtracks etc. that’s a waste of time to review.

For example I could review a new class that they heavily refactored in the next commit.

I’ve not had an issue with code reviews or backporting. I suspect this is because either out units of work are smaller than usual (no long feature branches)

But maybe you are onto something here and I’m missing out on a better way but I’ve not experienced enough pain in squashing on merge to master to contemplate switching to a rebase workflow (which means convincing team members too)