LGTMとは｜意味・使い方とレビュー略語一覧・Approveとの違い

プルリクエスト（PR）のレビューは、次の3つのどれかで返します。LGTM は「Approve（承認）」のときに添える言葉です。

flowchart TD
    P[プルリクエスト] --> R[レビュー]
    R -->|Comment| C[質問だけ]
    R -->|Request<br>changes| X[直して<br>再レビュー]
    R -->|Approve| M[LGTM<br>マージ可]
    X --> R

状況ごとに、書く言葉と GitHub での操作をまとめます。

確認環境：Ubuntu 24.04.4・Git 2.43.0・GitHub CLI（gh）2.45.0・Python 3.11.15。手元のリポジトリで main とレビュー対象のブランチを作り、PR と同じ範囲の差分（git diff main...feature）、git diff --check、テストの実行、指摘を受けた修正、Co-authored-by 付きのコミット、git request-pull、gh pr review のヘルプとエラーを実際に実行して確かめています。GitHub の Approve・Request changes・Comment、提案（suggested changes）、保護ブランチの動きは GitHub Docs（英語版・日本語版）、LGTM の使われ方は Google Engineering Practices・Chromium・Kubernetes・GitLab の公式ドキュメント、コメントのラベルは Conventional Comments、Grafana の LGTM スタックは Grafana Labs のブログ、LGTM.com の終了は GitHub Blog で確かめました（確認日 2026年10月22日）。

LGTMとは（意味・読み方・由来）

この節では、LGTM の意味と読み方、どこで使われてきた言葉かが分かります。

LGTM は英語の "Looks Good To Me" の頭文字で、「私には良さそうに見える」＝「問題ないと思う、承認します」という意味です。 コードレビューで、変更をマージしてよいと判断したときに書きます。設計書や文章のレビューでも使われます。

声に出して使うことは少なく、主に文字で書く言葉です。口頭では「LGTM です」「エルジーティーエムもらいました」のように使われます。

どこで使われてきた言葉か

最初に使った人や年ははっきりしていません（Dictionary.com の項目も起源の年は載せていません）。大きなオープンソースや企業の開発で、次のように正式な手順の言葉として使われています。

Google の指針には、LGTM を出す前に「このコードは基準を満たす」と確信できるだけの時間をレビューにかけること、とあります。LGTM は軽いあいさつではなく、「自分も確認した」という責任の表明です。

IT で「LGTM」が別の意味になる2つの例

検索で出てくる「LGTM」には、レビューの言葉とは別のものもあります。

この記事の LGTM は、コードレビューの「Looks Good To Me」です。

LGTMはいつ使う？（使う場面と例文）

この節では、LGTM を書く場面と書かない場面、もらったときの返し方が分かります。

逆に、次のときは LGTM を書きません。

LGTM の書き方の例

LGTM 1語だけでも意味は通じます。何を確かめたかを一言添えると、後から読んだ人にもレビューの深さが伝わります。

LGTM

LGTM! 境界値のテストが入ったので安心してマージできます。

LGTM with nits. 変数名の件は任意です。このままマージしてOKです。

LGTM（ローカルで python3 -m unittest が3件とも通るのを確認しました）

LGTM をもらったときの返し方

決まった返し方はありません。お礼と、次に何をするかを書くと会話が閉じます。

ありがとうございます！マージします。

ありがとうございます。nits の変数名は直してからマージします。

レビューありがとうございました。int の切り捨ての件は別の issue（#42）で相談します。

LGTM以外のコードレビュー略語の早見表

この節では、PR やチャットでよく見る略語40個の意味を、役割ごとに引けます。

レビューの略語は「賛否」「依頼と状態」「指摘の強さ」「会話」の4種類に分けると覚えやすくなります。

賛成・承認・反対

依頼・作業の状態

指摘の強さを伝える

会話でよく見る略語

英語のレビューや Issue のやり取りで見かけるものです。

大文字・小文字はどちらでも使われます（lgtm・ptal と小文字で書く人もいます）。チームの外の人や英語に慣れていない人が読むコメントでは、略語を使わずに書くと誤解がありません。

GitHubのApprove・Request changes・Commentの違い

この節では、GitHub のレビューの3つの種類と、LGTM を書くだけでは承認にならない理由が分かります。

GitHub でレビューを送るときは、Comment・Approve・Request changes の3つから1つを選びます。 LGTM は言葉で、Approve は GitHub に記録される「状態」です。ブランチの保護で「承認が必要」と設定されているリポジトリでは、Comment に「LGTM」と書いても承認の数には入りません。 Approve を選んで送ります。

画面でレビューを送る手順

保護ブランチの設定で変わること

リポジトリの管理者は、保護ブランチ（またはルールセット）で次の条件を付けられます。GitHub Docs によると、承認として数えられるのは、リポジトリへの書き込み権限を持つ人のレビューです。

「LGTM の後に1行だけ直して push した」場合、2つ目の設定が有効なら承認は取り消され、もう一度 Approve が必要です。

コマンドで送る（GitHub CLI）

gh の gh pr review でも、同じ3種類を送れます（gh 2.45.0 のヘルプで確認）。

GitHub につながっていないリポジトリ（remote が無い）で実行すると、次のエラーになりました。

$ gh pr review --approve -b "LGTM"
no git remotes found

remote が GitHub 以外（社内のサーバーなど）を指しているときは、次のエラーでした。

none of the git remotes configured for this repository point to a known GitHub host. To tell gh about a new GitHub host, please use `gh auth login`

gh の使い方全般は、関連記事「GitHub CLI（gh）の使い方｜逆引きコマンド一覧とjqレシピ」で扱っています。

GitLab・Gerrit では

LGTMと書く前に確かめること（チェックリスト）

この節では、Approve を押す前に確かめる10項目と、判断の流れが分かります。

• 1PR の目的が分かる説明文と関連する Issue を読み、何を直す・足す PR か一文で言える
• 2差分を全部読んだファイル数と行数を確かめ、読んでいないファイルが無い
• 3仕様どおりに動く説明・docstring・設計書と、条件（以上・より大きい）や計算が合っている
• 4境界と異常の値を考えた0・空・ちょうどの値・最大値・null・例外のときの動き
• 5テストがあり、通っている変更に合うテストが足され、CI が成功している
• 6余計なものが入っていないデバッグ出力・コメントアウト・生成物（キャッシュ・ビルド結果）・秘密情報
• 7読んで分かる名前・関数の大きさ・コメントが「なぜ」を説明している
• 8まわりへの影響を見た呼び出し元・他の画面・データ・性能に影響が無いか
• 9残った指摘の扱いが決まっている必須・任意を書き分け、任意だけなら LGTM with nits
• 10前回の指摘が直っている再レビューでは、前回レビューした時点からの差分を読む

Google の指針は、変更がシステム全体のコードの健全さを確実に良くする状態なら、完璧でなくても承認する方に傾けるべきだ、としています（「完璧なコードは無く、より良いコードがあるだけ」）。チェックリストは「完璧か」ではなく「マージして良くなるか」を確かめるためのものです。

判断の流れを図にすると次のとおりです。

flowchart TD
    A{目的と仕様が<br>分かる} -->|いいえ| Q[Comment<br>で質問]
    A -->|はい| B{必ず直す<br>点がある}
    B -->|ある| X[Request<br>changes]
    B -->|ない| C{任意の<br>指摘がある}
    C -->|ある| N[Approve<br>LGTM with nits]
    C -->|ない| L[Approve<br>LGTM]

Google の指針には「LGTM With Comments」という考え方もあります。レビュアーが、残りの指摘を作者が適切に直すと信頼できるとき、指摘が直さなくてもよいものだけのとき、import の並び替えや近くの誤字のような小さなものだけのときは、未解決のコメントを残したまま承認してよい、というものです。時差のあるチームで、作者が丸1日待たずに済むと説明されています。観点を優先順位つきで詳しく見たいときは、関連記事「コードレビューの観点チェックリスト｜優先順位と伝え方」で扱っています。

実際のdiffでレビューする（LGTMの前に見つけた3つの誤り）

この節では、PR と同じ範囲の差分を手元で作り、チェックリストで誤りを見つけてから LGTM に至るまでを実物で確かめます。

main に「価格の合計を返す total」があり、そこへ「5000円以上なら1割引き」を足すブランチ feature/discount を作りました。PR で表示される差分は、Git では main...feature/discount（ドット3つ）で同じ範囲を見られます。

$ git log --oneline main..feature/discount
e118e04 5000円以上で1割引きにする

$ git diff --stat main...feature/discount
 cart.py      | 9 +++++++++
 test_cart.py | 6 +++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

差分の中身です。

$ git diff main...feature/discount
diff --git a/cart.py b/cart.py
index ca5da4a..bb5e48c 100644
--- a/cart.py
+++ b/cart.py
@@ -1,3 +1,12 @@
 def total(prices):
     """商品の価格の合計を返す。"""
     return sum(prices)
+
+
+def discounted_total(prices):
+    """合計が5000円以上なら1割引きにする。"""
+    t = total(prices)
+    print("debug:", t) 
+    if t > 5000:
+        return int(t * 0.9)
+    return t
diff --git a/test_cart.py b/test_cart.py
index d15b1b3..37d557b 100644
--- a/test_cart.py
+++ b/test_cart.py
@@ -1,11 +1,15 @@
 import unittest
-from cart import total
+from cart import total, discounted_total


 class TotalTest(unittest.TestCase):
     def test_total(self):
         self.assertEqual(total([1000, 500]), 1500)

+    def test_discount(self):
+        self.assertEqual(discounted_total([6000]), 5400)
+        self.assertEqual(discounted_total([1000]), 1000)
+

 if __name__ == "__main__":
     unittest.main()

テストは通ります。テストが通ることは、仕様どおりであることと同じではありません。

$ python3 -m unittest -v
test_discount (test_cart.TotalTest.test_discount) ... debug: 6000
debug: 1000
ok
test_total (test_cart.TotalTest.test_total) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

チェックリストで見つけたこと

チェックリストの3・4（仕様と境界の値）で、docstring の「5000円以上」と条件の t > 5000（5000より大きい）が合っていないことに気づきました。ちょうどの値を渡して確かめると、5000円は割引になりませんでした。

$ python3 -c 'from cart import discounted_total
for p in (4999, 5000, 5001, 5555):
    print(p, "->", discounted_total([p]))'
debug: 4999
4999 -> 4999
debug: 5000
5000 -> 5000
debug: 5001
5001 -> 4500
debug: 5555
5555 -> 4999

チェックリストの6（余計なもの）では、print("debug:", t) が残っていました。git diff --check は、その行の末尾の空白も見つけて終了コード2を返しました。

$ git diff --check main...feature/discount
cart.py:9: trailing whitespace.
+    print("debug:", t) 

境界のテスト（4999円は割引なし・5000円は4500円）を足すと、テストが失敗して誤りがはっきりしました（実際の表示ではパスが出ます。ここでは省いています）。

$ python3 -m unittest
debug: 6000
debug: 1000
.debug: 4999
debug: 5000
F.
======================================================================
FAIL: test_discount_boundary (test_cart.TotalTest.test_discount_boundary)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "（作業フォルダのパス）/test_cart.py", line 15, in test_discount_boundary
    self.assertEqual(discounted_total([5000]), 4500)
AssertionError: 5000 != 4500

----------------------------------------------------------------------
Ran 3 tests in 0.000s

FAILED (failures=1)

このときのレビューコメント

見つけたことを、直す必要の強さが分かるように書き分けて送りました（ラベルは次の節の Conventional Comments の形）。結果は Request changes です。

issue (blocking): 5000円ちょうどが割引になりません。
docstring は「5000円以上」ですが、条件が t > 5000 なので 5000 は対象外です。
discounted_total([5000]) が 5000 を返すことを手元で確かめました。
>= にして、5000 と 4999 のテストを足すのはどうでしょう。

todo: print("debug:", t) が残っています（git diff --check で末尾の空白も出ます）。

question (non-blocking): int() で切り捨てているので 5555 円は 4999 円になります。
端数は切り捨てで仕様どおりでしょうか？

nitpick (non-blocking): t より subtotal のほうが読みやすいと思います。

praise: テストを同じ PR で足してくれているので、確かめやすかったです。

再レビューで見るのは「前回からの差分」

作者が直して push しました。指摘を取り込んだコミットには、GitHub の提案を取り込んだときと同じように Co-authored-by を付けています。

$ git log -1 --format=%B
5000円ちょうども割引の対象にする

レビューの指摘で境界値のテストを追加し、デバッグ用の print を削除。

Co-authored-by: reviewer <reviewer@example.com>

再レビューでは、前回レビューしたコミット（e118e04）からの差分を読みます。Python が作るキャッシュのファイル（__pycache__）がコミットに混ざっていました。

$ git diff e118e04 feature/discount
diff --git a/__pycache__/cart.cpython-311.pyc b/__pycache__/cart.cpython-311.pyc
new file mode 100644
index 0000000..907d895
Binary files /dev/null and b/__pycache__/cart.cpython-311.pyc differ
diff --git a/__pycache__/test_cart.cpython-311.pyc b/__pycache__/test_cart.cpython-311.pyc
new file mode 100644
index 0000000..9e231bf
Binary files /dev/null and b/__pycache__/test_cart.cpython-311.pyc differ
diff --git a/cart.py b/cart.py
index bb5e48c..61b1f44 100644
--- a/cart.py
+++ b/cart.py
@@ -6,7 +6,6 @@ def total(prices):
 def discounted_total(prices):
     """合計が5000円以上なら1割引きにする。"""
     t = total(prices)
-    print("debug:", t) 
-    if t > 5000:
+    if t >= 5000:
         return int(t * 0.9)
     return t

chore: __pycache__ が入っています。.gitignore に足して外してほしいです。 とコメントし、作者が外しました。最後の差分は3ファイル・18行の追加と1行の削除になり、テストは3件とも通りました。

$ git diff --stat main...feature/discount
 .gitignore   |  1 +
 cart.py      |  8 ++++++++
 test_cart.py | 10 +++++++++-
 3 files changed, 18 insertions(+), 1 deletion(-)

$ python3 -m unittest
...
----------------------------------------------------------------------
Ran 3 tests in 0.000s

OK

$ git diff --check main...feature/discount
（何も出ず、終了コード 0）

ここで初めて Approve を選び、次のまとめを送りました。

LGTM! 境界値（4999・5000）のテストと .gitignore を確認しました。
端数の扱い（question）は仕様の確認待ちなので、別の issue で続けます。

Git だけで「PR 相当」の依頼文を作る

GitHub が無くても、Git には git request-pull という、取り込みを頼む文面を作るコマンドがあります。PR の説明に載る「どこから・何コミット・何が変わったか」がそのまま出ます。

$ git request-pull main origin feature/discount
The following changes since commit 98aed92457126463eb031ef3a8866c93446acd67:

  合計を計算する total を追加 (2026-10-22 18:33:09 +0900)

are available in the Git repository at:

  ../origin.git feature/discount

for you to fetch changes up to 9544e1449a9af2954b052af9249e1565e5287a89:

  __pycache__ を管理対象から外す (2026-10-22 18:33:40 +0900)

----------------------------------------------------------------
rjc (3):
      5000円以上で1割引きにする
      5000円ちょうども割引の対象にする
      __pycache__ を管理対象から外す

 .gitignore   |  1 +
 cart.py      |  8 ++++++++
 test_cart.py | 10 +++++++++-
 3 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 .gitignore

レビューで使う差分の見方は次の表のとおりです。オプションの詳細は、関連記事「git diffの使い方｜オプション一覧とファイル名だけ・ブランチ間比較」で扱っています。

レビューコメントの書き方（例とラベル）

この節では、伝わるレビューコメントの形と、指摘の強さを伝えるラベルの付け方が分かります。

コメントは「何が・なぜ・どうするとよいか」の3つと、直す必要の強さを書きます。 Google の指針は、コメントに重さのラベル（Nit:・Optional:・FYI:）を付けて、必須の指摘と提案を区別することを勧めています。

Conventional Comments のラベル

コメントの先頭にラベルを付ける書き方に、Conventional Comments があります。形は ラベル (装飾): 本文 です。

装飾には (blocking)（解決するまで受け入れない）・(non-blocking)（受け入れを止めない）・(if-minor)（変更が小さく済むなら対応）があります。日本語のチームでは「[必須]」「[任意]」「[質問]」のような接頭辞で同じことをする書き方もあります。

レビューコメントの例を60個、ラベル別に見たいときは、関連記事「コードレビューのコメント例60｜ラベル別の書き方と言い換え表」で扱っています。

Suggested changes（提案）の使い方

この節では、GitHub の「提案」で、直したコードをそのまま渡す方法が分かります。

行コメントに suggestion という名前のコードブロックを書くと、作者がボタン1つでその変更をコミットできます。 画面では、行を選んでコメント欄の提案のアイコンを押すと、選んだ行がブロックに入るので、それを書き換えます。

5000円ちょうどが対象外になっています。

```suggestion
    if t >= 5000:
```

提案を受け取った作者は、次のどちらかで取り込みます（GitHub Docs より）。

取り込んだコミットでは、提案した人がそれぞれ共同作成者（co-author）になり、取り込んだ人が共同作成者かつコミットした人になります。取り込めるのは、リポジトリへの書き込み権限がある人です。手元では、前の節のように git commit --trailer "Co-authored-by: 名前 <メール>" で同じ形の記録を残せます。

LGTMの日本語での言い換え

この節では、略語を使わずに日本語で同じ意味を伝える書き方が分かります。

略語に慣れていない人や、エンジニア以外の人が読むコメントでは、日本語で書くと誤解がありません。

LGTM は日本の開発チームでもそのまま使われることが多い言葉です。チームの中で略語を使うかどうかは、PR のテンプレートやレビューの決まりに書いておくと揃います。

LGTM画像の貼り方

この節では、LGTM のコメントに画像を貼る文化と、その貼り方が分かります。

LGTM のコメントに「LGTM」の文字が入った画像を貼るチームもあります。承認の雰囲気をやわらげる目的で、LGTM 画像を作ったり探したりする Web サービス（LGTMoon など）やブラウザの拡張機能も公開されています。

GitHub のコメント欄では、画像を Markdown で書くか、ファイルをドラッグ＆ドロップして貼ります。

![LGTM](https://example.com/lgtm.png)

画像だけだと、何を確かめたかが残りません。画像を貼るときも、確かめた内容を一言添えると、後から履歴を読む人に伝わります。画像は承認の状態ではないので、承認が必要なリポジトリでは Approve を選んで送ります。

形だけのLGTMを防ぐ（大きなPRと承認ルール）

この節では、読まずに出す LGTM（いわゆるゴム印の承認）が起きる理由と、防ぐ工夫が分かります。

Google の指針は、変更の大きさについて「100行はたいてい妥当で、1000行はたいてい大きすぎる」としています（決まった上限は無く、1ファイル200行なら問題なくても、50ファイルにまたがると大きすぎることが多い、とも書かれています）。小さい変更は、早く・丁寧にレビューでき、不具合が入りにくく、戻しやすい、と理由も挙げられています。

PR の説明文の書き方は関連記事「プルリクエストの書き方｜レビューされやすい説明文とテンプレート」で、ブランチを分けて作業する流れは関連記事「ブランチとは｜Gitの作成・切り替え・マージと正体を実例で解説」で扱っています。

よくある質問

Q. LGTMとは何ですか？ A. 英語の "Looks Good To Me" の略で、コードレビューで「問題ないと思う、承認します」という意味です。GitHub では Approve と一緒に書くのが一般的です。

Q. LGTMの読み方は？ A. 「エル・ジー・ティー・エム」と、文字をそのまま読みます。主に文字で書く言葉で、声に出すことは多くありません。

Q. LGTMと言われたら、どう返せばいいですか？ A. 決まった形はありません。「ありがとうございます、マージします」のように、お礼と次にすることを書くと会話が閉じます。任意の指摘（nits）が残っていれば、直すか見送るかも書きます。

Q. LGTMとApproveの違いは？ A. LGTM はコメントに書く言葉、Approve は GitHub に記録されるレビューの状態です。承認が必要な保護ブランチでは、Comment に LGTM と書いても承認の数に入らないので、Approve を選んで送ります。

Q. 自分のPRにLGTM（Approve）できますか？ A. GitHub では、PR の作成者は自分の PR を承認できません。Kubernetes の Prow でも、作成者は自分の PR に /lgtm できません。

Q. LGTMは目上の人に使うと失礼ですか？ A. 開発のレビューでは立場に関係なく使われる言葉です。エンジニア以外の人や社外の人が読む場面では、「確認しました。問題ないので承認します」と日本語で書くと誤解がありません。

Q. nits（nit）とは？ A. nitpick（細かいことを指摘する）の略で、「直すかどうかは任意の小さな指摘」という意味です。複数あるときに nits と書きます。

Q. PTALとは？ A. "Please Take A Look" の略で、「見てください」というレビューの依頼です。指摘を直した後の再レビューの依頼にも使います。

Q. WIPとDraftの違いは？ A. WIP は「作業中」を表す言葉で、PR のタイトルに付けて使われてきました。Draft は GitHub の PR の状態で、マージできず、CODEOWNERS へのレビュー依頼も自動では送られません。「Ready for review」にすると依頼が送られます。

Q. SGTMとLGTMの違いは？ A. LGTM はコードや文書を見て「問題ない」、SGTM（Sounds Good To Me）は提案や方針を聞いて「それでよいと思う」という賛成です。

Q. LGTM画像とは？ A. 「LGTM」の文字が入った画像を、承認のコメントに貼る文化です。画像だけでは承認の状態にならないので、承認が必要なリポジトリでは Approve を選びます。

Q. GrafanaのLGTMとは？ A. Grafana Labs の監視の仕組みで、Loki（ログ）・Grafana（可視化）・Tempo（トレース）・Mimir（メトリクス）の頭文字です。"Looks good to me" にかけた名前で、レビューの LGTM とは別のものです。

まとめ

• LGTM は "Looks Good To Me" の略。コードレビューで「問題ないと思う、承認する」という意味。
• GitHub では言葉（LGTM）と状態（Approve）は別。承認が必要なリポジトリでは Approve を選ぶ。Request changes は既定ではマージを止めない。
• LGTM の前に、目的・差分の全部・仕様と境界の値・テスト・余計なもの・前回からの差分を確かめる。実物の diff では、テストが通っていても「5000円ちょうど」の誤りが見つかった。
• 指摘は「何が・なぜ・どうするか」と強さ（必須・任意・質問）を書き分ける。任意だけなら LGTM with nits。
• 略語はチームの外の人が読む場面では日本語に言い換える。

参考・出典

確認日はいずれも 2026年10月22日です。

• GitHub Docs「About pull request reviews」：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• GitHub Docs「プルリクエストで提案された変更をレビューする」：https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
• GitHub Docs「Reviewing proposed changes in a pull request」：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
• GitHub Docs「Incorporating feedback in your pull request」：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
• GitHub Docs「About protected branches」：https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• GitHub Docs「About pull requests」：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
• GitHub CLI マニュアル「gh pr review」：https://cli.github.com/manual/gh_pr_review
• GitHub CLI マニュアル「gh pr diff」：https://cli.github.com/manual/gh_pr_diff
• Google Engineering Practices「The Standard of Code Review」：https://google.github.io/eng-practices/review/reviewer/standard.html
• Google Engineering Practices「Speed of Code Reviews」：https://google.github.io/eng-practices/review/reviewer/speed.html
• Google Engineering Practices「How to write code review comments」：https://google.github.io/eng-practices/review/reviewer/comments.html
• Google Engineering Practices「What to look for in a code review」：https://google.github.io/eng-practices/review/reviewer/looking-for.html
• Google Engineering Practices「Small CLs」：https://google.github.io/eng-practices/review/developer/small-cls.html
• Chromium「Code Reviews」：https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_reviews.md
• Kubernetes「OWNERS files」：https://www.kubernetes.dev/docs/guide/owners/
• GitLab Docs「Merge request approvals」：https://docs.gitlab.com/user/project/merge_requests/approvals/
• Conventional Comments：https://conventionalcomments.org/
• Dictionary.com「LGTM」：https://www.dictionary.com/e/acronyms/lgtm/
• Grafana Labs「Open source at Grafana Labs in 2022: Year in review」：https://grafana.com/blog/grafana-labs-open-source-projects-2022
• GitHub Blog「The next step for LGTM.com: GitHub code scanning!」：https://github.blog/news-insights/product-news/the-next-step-for-lgtm-com-github-code-scanning

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。