From 249140d6e830660705659bab52c1db18a08cd5b2 Mon Sep 17 00:00:00 2001 From: Janghoon Lee <44862514+savagemanage@users.noreply.github.com> Date: Wed, 7 Oct 2026 13:50:32 +0000 Subject: [PATCH] docs(contributing): small commits are fine; keep PRs focused and deduplicated Add a rule to the Commits section (en + ko): fine-grained commits are encouraged, but a pull request should be one thing, deduplicated, and no larger than it needs to be. Squash the churn, drop changes already on the base, and keep it to a change a reviewer can state in one sentence. --- CONTRIBUTING.ko.md | 10 ++++++++++ CONTRIBUTING.md | 11 +++++++++++ 2 files changed, 21 insertions(+) diff --git a/CONTRIBUTING.ko.md b/CONTRIBUTING.ko.md index 4ede201..9141683 100644 --- a/CONTRIBUTING.ko.md +++ b/CONTRIBUTING.ko.md @@ -72,6 +72,16 @@ fix(composer): show the drop zone during dragover, not only on drop em dash는 어디에도 쓰지 않습니다. 커밋, 풀 리퀘스트, 코드 주석, 문서 모두 그렇습니다. +커밋은 얼마든지 잘게 쪼개도 됩니다. 잘게 나뉜 이력은 좋습니다. 한 커밋에 논리적 단계 하나면 변경을 +읽기도 되돌리기도 쉽습니다. 마음껏 쪼개십시오. + +풀 리퀘스트는 반대 단위입니다. 한 가지만 담고, 중복을 걷어내고, 필요한 크기를 넘지 않게 하십시오. 열기 +전에 군더더기를 정리하십시오. "오타 수정", "앗", 되돌림의 되돌림 같은 커밋은 스쿼시하고, 베이스 +브랜치에 이미 있는 변경은 빼고, 리뷰어가 진짜 변경을 판단하려고 머릿속에서 치워 둬야 하는 것은 넣지 +마십시오. 리뷰어가 이 PR이 무엇을 하는지 한 문장으로 말할 수 있어야 합니다(그 문장이 템플릿의 첫 +줄입니다). 한 문장을 넘으면 그 브랜치는 두 가지를 하고 있는 것이고, PR 두 개로 나눠야 합니다. 한 가지 +목적의 좁은 PR 안에 작은 커밋이 여럿 있는 것, 그것이 우리가 바라는 모양입니다. + ## 풀 리퀘스트를 열기 전에 저장소 자신의 게이트를 돌립니다. `README.md` 에 적혀 있습니다. 저장소마다 다르므로 추측하지 말고 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 09a32aa..253fa83 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -72,6 +72,17 @@ discussion may be in Korean or English, and nobody will ask you to switch. No em dashes, anywhere: commits, pull requests, code comments, documentation. +Commits can be as small as you like. A fine-grained history is good: one logical step per commit +makes a change easy to read and easy to revert. Split freely. + +A pull request is the opposite unit. Keep it to one thing, deduplicated and no larger than it +needs to be. Before you open one, fold away the noise: squash the "fix typo", "oops" and +revert-of-a-revert churn, drop a change that is already on the base branch, and leave out +anything a reviewer would have to mentally set aside to judge the real change. A reviewer should +be able to say in one sentence what the PR does (that sentence is the template's first line); if +it takes more, the branch is doing more than one thing and should be two PRs. Small commits +inside a tight, single-purpose PR is exactly the shape we want. + ## Before you open a pull request Run the repository's own gates, listed in its `README.md`. They differ per repository, so read