TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Things I know about Git commits

118 点作者 sea-gold10 个月前

19 条评论

anyfoo10 个月前
`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&#x27;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&#x27;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&#x27;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&#x27;ve never had to use `git reflog` <i>that</i> far in the future.
评论 #40952599 未加载
评论 #40951917 未加载
评论 #40955109 未加载
评论 #40952732 未加载
评论 #40953330 未加载
评论 #40956486 未加载
评论 #40951769 未加载
donatj10 个月前
&gt; People who say &quot;just delete the repo&quot; when things go wrong really frustrate me<p>YES. Go be a baker or something! If you&#x27;re going to be a developer you should generally speaking be willing to figure out what&#x27;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:&#x2F;&#x2F;donatstudios.com&#x2F;yagni-git-gc" rel="nofollow">https:&#x2F;&#x2F;donatstudios.com&#x2F;yagni-git-gc</a><p>99% of people should just turn automatic `git gc` off. You don&#x27;t need it. Turn it off and you never have to worry about losing work. It&#x27;s there, you just have to find it.
评论 #40952626 未加载
评论 #40951933 未加载
评论 #40951905 未加载
评论 #40952690 未加载
alganet10 个月前
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&#x27;s a superpower that a team can cultivate.
评论 #40951336 未加载
评论 #40953378 未加载
JelteF10 个月前
The most effective way I&#x27;ve found to get other people to &quot;write&quot; good commit messages is by changing the &quot;Default commit message&quot; for squash merges on the GitHub repo to &quot;Pull request title and description&quot;. [1]<p>That fixes the &quot;Squashing, when you have 100 crap commits, and then not re-editing the message is a crime&quot; item, because suddenly not re-editing will give you a fairly useful message. This ofcourse assumes the PR description is useful, but I&#x27;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:&#x2F;&#x2F;github.blog&#x2F;changelog&#x2F;2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.blog&#x2F;changelog&#x2F;2022-08-23-new-options-for-con...</a>
评论 #40953352 未加载
评论 #40953447 未加载
lucasoshiro10 个月前
If you want more controversial things about squash, here are two that I posted here last week:<p>1. &quot;How squash merge can break Git repos with submodules&quot;, about a situation where squash merges silently broke a repository: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40846596">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40846596</a><p>2. &quot;Git: please stop squash merging!&quot; giving some technical explanation about what squash merges actually are under the hood and how the misconceptions about Git leads to invalid &quot;pros&quot; about squash merging: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40840572">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40840572</a>
评论 #40954878 未加载
jenadine10 个月前
It frighten me how some contributor to my open source repo just don&#x27;t care about their git history. They do 100 of &quot;crap&quot; commits (author&#x27;s wording) and merge commits. Sometimes I&#x27;d write a comment like: &quot;can you please rebase your branch&quot; and even very senior software engineer are clueless and can&#x27;t do it even if I give the exact git command i&#x27;d use. In the end it&#x27;s simpler for me to do it myself.<p>Some developers don&#x27;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.
评论 #40952504 未加载
metadat10 个月前
<i>&gt; Do the work up front to make your history atomic</i><p>Is this saying 1 feature &#x2F; main &quot;idea&quot; per commit?<p>Overall this post is gold, but also probably preaching to the choir. IME it&#x27;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.
评论 #40951410 未加载
jraph10 个月前
&gt; Make sure you review your own code changes<p>The author says he reviews himself on a GitLab MR &#x2F; 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&#x27;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.
评论 #40952482 未加载
评论 #40952519 未加载
评论 #40952578 未加载
at_a_remove10 个月前
Ah, the endless mysteries of git. People say, &quot;It&#x27;s so simple once you understand the base model.&quot; 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 &quot;merging ... merges&quot; 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.
cxr10 个月前
&gt; 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&#x27;re generally going to have something to fix because of that &quot;bad assumption&quot;, 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 &quot;annotate&quot; 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&#x27;s optional).<p>2. Merge the mainline into this HEAD&#x2F;branch, making sure force a merge commit using --no-ff, and write your &quot;annotation&quot; in the commit message.<p>3. Merge that into the mainline branch.
yerdoingitwrong10 个月前
The most USELESS commit messages are &quot;Fixes #12345 (#23456)&quot;. It tells the git log reviewer NOTHING. You shouldn&#x27;t have to rely on github to understand your project. State the intent of the bug fix in the commit message.
评论 #40952176 未加载
评论 #40952655 未加载
评论 #40952269 未加载
g-b-r10 个月前
PLEASE, recognize that &quot;atomic&quot; 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&#x27;ll have both your &quot;atomic commits&quot;, 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&#x27;ll retain the ability to browse the history at a higher abstraction level (either use any decent graphical git browser, or simply --first-parent).
评论 #40952720 未加载
usr110610 个月前
I agree with most of the items on the list. But some are too short to understand what they mean or they are really &quot;It depends&quot;.<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&#x27;t get the context switch right between those 2 modes of operation. Or just don&#x27;t do the second phase because I first need fo fix a bug and will continue with the current branch later.
MaryBeew10 个月前
Fighting to restore love and peace in my relationship was so frustrating until I saw a video of a lady&#x27;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 )
joshka10 个月前
Agreed with this pretty much 100%. I&#x27;d add to the list:<p>- oh my zsh git shortcuts are great<p>- git-extras (especially git-brv for when you&#x27;re an open source library maintainer)<p>- pushing to PR submitter&#x27;s branches to clean up a PR ready for merge is a good skill to know
r-s10 个月前
&gt; 58. Trying to police commit history is going to be painful<p>This has been my experience. Very painful
osigurdson10 个月前
&gt;&gt; Squashing is better than 100 crap commits<p>Unless your work is trivial, you will have crap commits. Have discipline but don&#x27;t insist on working on trivial things just so your commits appear logical without rework.
评论 #40952196 未加载
评论 #40952255 未加载
dougthesnails10 个月前
Be still my heart.
khana10 个月前
and the winner: Do the work up front to make your history atomic