Things I know about Git commits

If you don't know about it, it is well worth checking it out now.

It is your one ticket to getting to whatever previous, good (or bad!) state you were at any point before[1]. The only thing it cannot help you recover is locally made changes that you never committed to anything at any point, and have since locally deleted. This is surprisingly rare, at least for me, as I just tend to `git stash` stuff I don't want anymore.

With `git reflog` in your backpocket, you can rebase, merge, branch, delete branches, cherry-pick, rewrite history, whatever, all to your heart's content. `git reflog` keeps a journal of every single action, and tells you the HEAD before and after each action, which you can then simply checkout or `reset --hard` your branch to.

I never even use any arguments with it, I literally just `git reflog`.

[1] Unless garbage collection has deleted the commit you were pointing to, I guess, but I've never had to use `git reflog` that far in the future.

YES. Go be a baker or something! If you're going to be a developer you should generally speaking be willing to figure out what's wrong and how to fix it.

Know how your tools work. Bad carpenter what have you...

Also speaking of `git reflog` and such - I still stand by this article I wrote a few years back - https://donatstudios.com/yagni-git-gc

99% of people should just turn automatic `git gc` off. You don't need it. Turn it off and you never have to worry about losing work. It's there, you just have to find it.

Opening an unknown file and having the option to see all it went through is powerful. The commit messages and history will tell you which files are related, which files change together, why they do, etc.

It's a superpower that a team can cultivate.

That fixes the "Squashing, when you have 100 crap commits, and then not re-editing the message is a crime" item, because suddenly not re-editing will give you a fairly useful message. This ofcourse assumes the PR description is useful, but I've found it much easier to convince people to write a decent PR description than to write decent commit messages.

[1]: https://github.blog/changelog/2022-08-23-new-options-for-con...

1. "How squash merge can break Git repos with submodules", about a situation where squash merges silently broke a repository: https://news.ycombinator.com/item?id=40846596

2. "Git: please stop squash merging!" giving some technical explanation about what squash merges actually are under the hood and how the misconceptions about Git leads to invalid "pros" about squash merging: https://news.ycombinator.com/item?id=40840572

Some developers don't even use git and just use some UI on top.

I wish GitHub would have an interface to do interactive rebase and edit commit messages.

Is this saying 1 feature / main "idea" per commit?

Overall this post is gold, but also probably preaching to the choir. IME it's challenging to convert non-believers to the faction of Orthodox Git.

For me, learning the ins and outs of Git felt like uncovering a part of myself which has always been there. Nothing new was created, only revealed.

The author says he reviews himself on a GitLab MR / GitHub PL, I rely on two things for this:

- git add -p, which also helps me split stuff in several commits if needed. It bothers me that it doesn't work for new files.

- git difftool dir-diff for changes with several commits

I like that it would work on any git hosting, and that it works locally. And that I can just amend my commits if I see something.

One day I hope to have a positive and comprehensible experience involving git and perhaps even git and another programmer, but that might be too much to ask.

You rarely want to do _just_ this, i.e. call out the bad commit message in question and nothing else; you're generally going to have something to fix because of that "bad assumption", too. You just branch off the old commit, do the needful (read: make the correction to the code), commit it, and then merge that into mainline. It seems like a lot of people fail to consider that a branch merged into mainline does not become immutable; at any point you can check it out and make further changes and then remerge those and do all of this as many times as necessary.

If you really do need to only draw attention to a bad commit message in a past commit and correct the record but nothing else, then you can just "annotate" it with an ordinary merge commit—

1. Check out the old commit that you want to annotate (create a branch there if you want, but it's optional).

2. Merge the mainline into this HEAD/branch, making sure force a merge commit using --no-ff, and write your "annotation" in the commit message.

3. Merge that into the mainline branch.

If you like to see chains of commits each with a complete feature, just remember that merge commits are commits as well!

Sure, rebase a feature branch before merging it, but then merge it with a merge commit ! (merge --no-ff)

That way you'll have both your "atomic commits", and actually atomic commits, that is commits with changes that any diff program will be able to highlight correctly. Verification will be extremely easier, but you'll retain the ability to browse the history at a higher abstraction level (either use any decent graphical git browser, or simply --first-parent).

The most important point for me is that the same tool is used for 2 purposes: Keeping track of quick trial and error experiments so that you can return to the best one once you have made up your mind. And producing a readable story of self-contained atomic commits telling a story to the reviewer and yourself weeks or years later.

I hate myself every time when I don't get the context switch right between those 2 modes of operation. Or just don't do the second phase because I first need fo fix a bug and will continue with the current branch later.

- oh my zsh git shortcuts are great

- git-extras (especially git-brv for when you're an open source library maintainer)

- pushing to PR submitter's branches to clean up a PR ready for merge is a good skill to know

This has been my experience. Very painful

Unless your work is trivial, you will have crap commits. Have discipline but don't insist on working on trivial things just so your commits appear logical without rework.