TechEarl

Code Review and Git Jokes: Nitpicks, Merge Conflicts, and LGTM

100+ jokes on one page, grouped by subject: git merge conflict jokes, and more.

Ishan Karunaratne⏱️ 3 min readUpdated
Share thisCopied
Code review humor about LGTM rubber stamps, 47 nit comments, 800-line PRs, bikeshedded variable names, force-push comment loss, and reviewers stuck on PTO.

60 Code Review Jokes

LGTM is short for I did not read it.

I opened a PR. A reviewer left one comment. The comment was nit. The PR has been open for six days.

The PR was 800 lines. It got two comments. The first PR I opened that week was three lines. It got nineteen.

Reviewer A approved. Reviewer B requested changes. Reviewer A requested changes on the changes from Reviewer B. I am now a hostage negotiator.

Someone left a comment that said consider extracting this. No suggestion. No example. Just consider. I have considered. I am still considering.

I once approved a PR without reading it. It deleted the database. I learned to read PRs. My blame still shows my approval. The blame is forever.

The reviewer was on PTO. They were the only reviewer on the file. The file required two approvals. The PTO was three weeks. The bug was in production. The fix shipped after the vacation.

I left 47 nit comments. The author asked if I wanted to pair on it. I said no. I wanted to nit on it.

The CI passed. The reviewer asked for tests. I added tests. The CI passed again. The reviewer asked for more tests. I added more tests. The CI passed a third time. The reviewer left for lunch.

I asked a senior to review. She asked why the function existed. I deleted the function. The PR is now negative 40 lines. This is the best review I have ever had.

I rebased and force-pushed. The reviewer's comments lost their anchor. They asked me to leave the comments in place next time. I do not know how to do that. I have not figured it out in five years.

Someone bikeshedded the variable name for three days. The variable was used once, in a private function, that ran twice a year.

The comment said this is a personal preference, feel free to ignore. The comment was from the staff engineer. I changed it. I have a mortgage.

Resolved was a button. The reviewer un-resolved it. I re-resolved it. They un-resolved it again. We have been doing this for an hour. The PR is still open.

I approved a PR that broke production. The author approved a PR of mine that broke production a week later. We are now friends.

The PR description said small refactor. It touched 84 files. The CI passed because the tests were also part of the refactor.

I asked for screenshots. They sent a Loom. The Loom was 18 minutes long. The change was one CSS rule.

The author marked the PR as draft. It has been a draft for four months. The branch is six thousand commits behind. We agreed it was load bearing draft.

I left a comment that said this needs a comment. They added a comment that said see PR review for context. The context is the PR I am asking them to put in a comment.

The senior approved with a single emoji. It was a thumbs up. I have analyzed it for an hour. I think it means ship it. I am 70 percent sure.

I marked a comment as resolved. The reviewer wrote a follow-up that said please do not resolve my comments. I resolved that one too. The PR is still open.

There is a rubber-stamp approver on every team. There is also a stop-energy reviewer on every team. The trick is to learn which one is which before you tag them.

The author rewrote the function as a one-liner. The one-liner used three new operators I had never seen. The reviewer approved it. The on-call had to read it at 3am. The on-call did not approve.

I asked for a code review. I got a code rewrite. The reviewer pushed a commit. The commit is now in my history. I have to defend it forever.

The PR title was wip. It was merged. The title is now the commit message. The release notes pulled from the commit message. The release notes say wip.

I rebased to clean up the history. The history is now perfect. The CI failed on every intermediate commit. Bisect cannot use any of them.

I once left a comment that said I disagree but I will not block. They did the thing anyway. It broke the thing I said it would break. The blame is on me. I left the comment. I did not block.

Self-approval is on for hotfixes. Everything is now a hotfix. The team has not done a code review since November.

The PR was up for ten days. The author wrote a Slack message that started with friendly bump. The reviewer was on a different team. The reviewer left the company last week.

I commented on a line. The author moved the line. The comment now anchors to a blank line. The conversation is still about the moved line. The blank line has feelings.

Two reviewers approved. A third reviewer self-added and requested changes. The change request was about formatting. The formatter had not run. The formatter is a CI step. The CI was green.

I write better PR descriptions than commit messages. I write better commit messages than my code. I write better code than my tests. The tests are perfect.

I asked the reviewer how long the PR would take. They said end of day. The day was Wednesday. The year was unspecified.

The reviewer left a thread of 23 comments. They all said the same thing in slightly different words. The author addressed the first one. The reviewer marked the others resolved. The thread is now folklore.

I tagged five reviewers. Four ignored it. One approved. The one was the new hire. The new hire approved everything for their first month. We did not warn them.

Code review is the only meeting where one person does all the work and four people show up to disagree.

I once approved my own PR by accident. GitHub let me. The merge button lit up. The merge happened. The PR was wrong. The audit log is unkind.

The PR template asked for a test plan. The test plan said tested locally. The local environment differed from production in three ways the author had not noticed. The PR shipped. The third way found out.

I left a comment that asked are we sure about this. The author replied yes. I clicked approve. I am still not sure. They are not sure. We shipped anyway.

I once left a code review at 5:20am. It was lucid. The author said it was the best review they had received that quarter. I do not remember writing it. I do not want to know what I am like at 5:20am.

The PR closed three open issues. It opened four new ones. The math is correct. The team accepted it. We are a debt-driven organization.

The reviewer asked for a benchmark. I wrote a benchmark. The benchmark showed the change was slower. I deleted the benchmark. I shipped the change. The reviewer never asked again.

Stacked PRs sounded efficient. The base PR was merged. The stacked PRs all need rebasing. The rebase has eight conflicts per PR. I have three PRs left. I am rebasing.

Someone left a comment that said we should refactor this. The PR is a bug fix. The bug is in production. The refactor is a half day. The bug fix is two lines. I closed the comment with a thumbs up and ignored it.

I once left every comment as a suggestion block. The author clicked apply on all of them. The PR was now my code. The blame was theirs. I have done this on purpose ever since.

The PR was marked ready for review. The CI was red. The author tagged reviewers. The reviewers approved. The CI was still red. The PR merged via emergency override. It is now Tuesday.

I asked a junior to review my code. They approved in three minutes. They had not read it. I had not expected them to. We both played our parts. The PR shipped.

Conventional comments shipped. The team adopted them for two weeks. Then someone wrote a comment that started with nit:. The comment was about the nit prefix. The convention died on the spot.

I requested changes on a docs PR. The author had been on the team for nine years. I had been on the team for two weeks. The change was correct. The team is now talking to HR.

The reviewer left a comment that said see Slack DM. There is no Slack DM. The reviewer is asleep. The DM does not exist. The PR is now archaeology.

The PR is approved. The merge button is gray. There is a required check that has not run. The check has not run because the CI runner is down. The CI runner has been down since lunch.

I asked the reviewer for context. They wrote a 400-word reply. The reply made the original concern bigger. The PR is now a feature request. I closed it. I will rewrite it next quarter. I will not.

The PR description has nine bullet points. The code is one line. The disparity is the point. I am building credit for next quarter.

Two approvals required. The second approver is always the bottleneck. The first approver knows this. The first approver tags the second approver. The second approver is the first approver of someone else's PR. The cycle is the team.

I added a screenshot to the PR. The screenshot was a meme. The reviewer left a comment that said cute. Approved. I am keeping the meme strategy.

The reviewer left a 200-line comment explaining a design tradeoff. The comment was on a typo. The typo had triggered a deeper memory. The memory had been waiting eighteen months for an outlet.

I once labeled a PR do not review yet. Three people reviewed it. They all left comments. The comments were good. I addressed them. The PR was no longer the PR I had wanted. It was better.

Squash and merge erased six commits. One of those commits was the bug fix. The squash message says feature. The bug came back. The fix is now a story I tell, with no commit to point at.

Merge conflicts during review are a different bug from merge conflicts during deploy. The first is a long conversation. The second is a panic. Both end with three people in a meeting.

I have approved every PR this week. I have not read any of them. The team has shipped twelve features. None of them have broken. I am beginning to wonder what reviews are for.

Why code review humor never lands wrong

Every working engineer has been on both sides of a stalled PR. The author who friendly-bumps a reviewer for the fourth time, and the reviewer who logs in to a queue of seventeen PRs and picks the three-liner because the 800-line refactor would eat the morning. The same person is both of these people, on the same day, sometimes in the same hour.

Code review humor lands because the review process is fundamentally about humans queueing for each other's attention, with a CI pipeline and a merge button as the props. The shape of the joke does not change when the platform changes. GitHub, GitLab, Gerrit, Phabricator, the new tool your CTO read about on a podcast — the LGTM stays. The nit comment stays. The reviewer on PTO during the deploy freeze stays.

Git Merge Conflict Jokes Jokes

I opened the file and saw <<<<<<< HEAD. I closed the laptop and went for a walk.

Ours or theirs. Nobody on this team has ever been sure which one is which.

I resolved the conflict by deleting both sides and writing what I thought the code should be. The tests still pass. The product manager does not.

I rebased a feature branch. Two hours later I was rebasing my will to live.

Force pushed to main. The Slack channel went so quiet I could hear my own keyboard.

git reflog is not a command. It is a prayer.

Junior asked why his branch had 47 commits called fix. I told him that is just how legends are born.

The PR description said small change. The diff was 4,200 lines and most of them were package-lock.json.

I cherry-picked a commit. It brought four friends I did not invite.

git stash pop. Nothing came out. Somewhere in the multiverse, a different version of me is still working on that feature.

Conflict in package-lock.json. I deleted it, ran install, and prayed to whichever god runs npm this week.

We had a binary file conflict. I picked the bigger one because it looked more important.

Detached HEAD state. That is also how I feel during planning poker.

I asked the new hire if she had pulled. She said yes. She had not pulled.

git reset --hard is the only therapy my insurance covers.

Squash merge took 12 commits called wip and turned them into one commit called wip.

The merge was clean. That is when I knew something was very wrong.

I accidentally pushed to prod. Then I un-accidentally pushed a fix to prod. Then I claimed both were intentional.

The git history looks like a subway map drawn by a toddler.

Fast-forward merge. The only thing in my life that has ever moved forward without a meeting.

I opened a file and found a commit by someone whose name I did not recognize. I checked the company directory. They left in 2019.

The .gitignore that we needed was never checked in. So every laptop on the team has its own private rebellion.

I rebased onto main. Main rebased onto me. We are now married in seven states.

Three people are typing in the conflict resolution channel. None of them have touched the file.

I force-pushed over a colleague's work. We do not speak anymore. Mostly because he is still searching the reflog.

Git is distributed. The blame is centralized.

Typo in the commit message reads coomit fix. It will outlive the company.

The senior engineer said merge conflicts are easy. Then she opened the file and went very still.

I resolved a conflict by taking ours. It turned out ours was theirs. It turned out theirs was mine from yesterday.

A junior asked me if rebase rewrites history. I said yes and so do politicians.

Two engineers, one file, one weekend. The merge took longer than the feature.

The repo has 14 branches called test, test2, test-real, test-final, and test-final-FINAL. Main is somewhere in there.

I once spent four hours on a conflict. The resolution was choosing the line that already existed in both files.

Nothing focuses the mind like the word rebase in a calendar invite.

git log --oneline --graph is just modern art at this point.

The PR has 47 commits called fix and one commit called actually fix. Reviewer approved without reading.

I asked git who broke the build. Git said I did. Git was right and I have never forgiven it.

The conflict was in a generated file. I regenerated it. It produced a different conflict in a different generated file.

Pre-commit hook caught my mistake. Then I added --no-verify and made the mistake anyway. This is the developer's free will.

The git stash list has entries from 2022. I am not throwing them away. One of them might be the cure for cancer.

Twenty-five years of shipping software and the scariest sentence I still hear is, I think I resolved it correctly.

Two branches drifted for six months. The merge had 300 conflicts. I ran git checkout --ours on everything and told the other team their work was, in spirit, included.

The conflict markers appeared. Both sides were byte-for-byte identical. Git just wanted me to feel something.

Nobody set up .gitattributes. The Windows dev and the Mac dev have been silently rewriting every line of every file to each other for three years. The diffs are a private language only they understand.

Junior committed a 400 MB binary on Tuesday. We noticed on Friday. The repo now ships with its own warning label.

Pushed the .env to a public repo. Force-pushed over it in ninety seconds. GitHub had already shown it to a bot in eleven.

The merge queue rejected my PR for failing tests. The tests pass locally. The merge queue does not care about my feelings or my laptop.

Rebase or merge is not a technical question. It is a personality test. And I have learned not to date the rebasers.

CODEOWNERS demanded a reviewer who left the company in 2023. I removed the file. The PR description for that change is one sentence: it's fine.

Opened a PR. The description was a single screenshot of the Jira ticket. The Jira ticket description was a single screenshot of a Slack message. The Slack message said, you know what I mean.

See also

Sources

Authoritative references this article was fact-checked against.

TagsHumorJokesCode ReviewPull RequestsGitHubEngineering ProcessTech Humor

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Systems and Network Architect · Chief Technology Officer

Systems and network architect and Chief Technology Officer with more than two decades designing, building, and running production software, cloud and network architecture, Linux systems, and the bare metal underneath them, and lately working AI into the stack. A US Army veteran who served in Operation Iraqi Freedom. What I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.

Keep reading

Related posts

How to resolve merge conflicts in Git by editing conflict markers and committing the result

How to Resolve Merge Conflicts in Git

A merge conflict means Git found two changes to the same lines and needs you to pick. Here is how to read the conflict markers, fix them by hand or with a mergetool, and commit.