`git reflog`, which the article prominently mentions, really should be the VERY FIRST thing to teach everyone who is learning git.<p>If you don't know about it, it is well worth checking it out now.<p>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.<p>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.<p>I never even use any arguments with it, I literally just `git reflog`.<p>[1] Unless garbage collection has deleted the commit you were pointing to, I guess, but I've never had to use `git reflog` <i>that</i> far in the future.
> People who say "just delete the repo" when things go wrong really frustrate me<p>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.<p>Know how your tools work. Bad carpenter what have you...<p>Also speaking of `git reflog` and such - I still stand by this article I wrote a few years back - <a href="https://donatstudios.com/yagni-git-gc" rel="nofollow">https://donatstudios.com/yagni-git-gc</a><p>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.
To me, commit messages really shine on file histories and `git blame`.<p>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.<p>It's a superpower that a team can cultivate.
The most effective way I've found to get other people to "write" good commit messages is by changing the "Default commit message" for squash merges on the GitHub repo to "Pull request title and description". [1]<p>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.<p>[1]: <a href="https://github.blog/changelog/2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request/" rel="nofollow">https://github.blog/changelog/2022-08-23-new-options-for-con...</a>
If you want more controversial things about squash, here are two that I posted here last week:<p>1. "How squash merge can break Git repos with submodules", about a situation where squash merges silently broke a repository: <a href="https://news.ycombinator.com/item?id=40846596">https://news.ycombinator.com/item?id=40846596</a><p>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: <a href="https://news.ycombinator.com/item?id=40840572">https://news.ycombinator.com/item?id=40840572</a>
It frighten me how some contributor to my open source repo just don't care about their git history. They do 100 of "crap" commits (author's wording) and merge commits. Sometimes I'd write a comment like: "can you please rebase your branch" and even very senior software engineer are clueless and can't do it even if I give the exact git command i'd use. In the end it's simpler for me to do it myself.<p>Some developers don't even use git and just use some UI on top.<p>I wish GitHub would have an interface to do interactive rebase and edit commit messages.
<i>> Do the work up front to make your history atomic</i><p>Is this saying 1 feature / main "idea" per commit?<p>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.<p>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.
> Make sure you review your own code changes<p>The author says he reviews himself on a GitLab MR / GitHub PL, I rely on two things for this:<p>- 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.<p>- git difftool dir-diff for changes with several commits<p>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.
Ah, the endless mysteries of git. People say, "It's so simple once you understand the base model." And yet there are these inevitable <i>buts</i>. And somehow, people keep arguing over how to use it, what is the Correct Way. If it were that simple, the One True methodology would be obvious, yet the disagreements continue. Then I ask dumb questions about merging and have yet to hear how the magic happens, just very circular "merging ... merges" answers.<p>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.
> There needs to be a way to add an annotation[...] to a previous message to correct assumptions<p>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.<p>If you really do need to <i>only</i> 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—<p>1. Check out the old commit that you want to annotate (create a branch there if you want, but it's optional).<p>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.<p>3. Merge that into the mainline branch.
The most USELESS commit messages are "Fixes #12345 (#23456)".
It tells the git log reviewer NOTHING.
You shouldn't have to rely on github to understand your project.
State the intent of the bug fix in the commit message.
PLEASE, recognize that "atomic" commits as the author defines them (basically whole features), will actually jumble up a large part of the diff, however much advanced your diff program is, making verifying the changes a lot harder..!<p>If you like to see chains of commits each with a complete feature, just remember that merge commits are commits as well!<p>Sure, rebase a feature branch before merging it, but then merge it with a <i>merge commit</i> ! (merge --no-ff)<p>That way you'll have both your "atomic commits", and <i>actually atomic</i> 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).
I agree with most of the items on the list. But some are too short to understand what they mean or they are really "It depends".<p>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.<p>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.
Fighting to restore love and peace in my relationship was so frustrating until I saw a video of a lady's testimony talking about how are marriage was restored. It was a whole experience I never thought could have been possible. My partner and I are happily reunited in Love and harmony, All thanks to priest Mandla for the Help he rendered to me and my family. You can still save your marriage or relationship, email: ( supremacylovespell01 @ gmail. com )
Agreed with this pretty much 100%. I'd add to the list:<p>- oh my zsh git shortcuts are great<p>- git-extras (especially git-brv for when you're an open source library maintainer)<p>- pushing to PR submitter's branches to clean up a PR ready for merge is a good skill to know
>> Squashing is better than 100 crap commits<p>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.