전통적인 커밋으로는 커밋 메시지를 구할 수 없습니다

인터넷을 빠르게 검색하면 커밋 메시지를 작성하는 방법을 가르치는 수많은 글을 찾을 수 있습니다. 이 글의 90%는 전통적인 커밋을 사용하라고 합니다. 그러나 여전히 많은 개발자가 이에 어려움을 느끼고 있습니다. 이들은 이러한 규칙을 따라야 한다는 것을 알고 있지만, 실제 적용은 어렵다고 생각합니다. 매번 코드를 커밋할 때마다 "리팩터" 또는 "작업"을 작성해야 할지 고민합니다. 심지어 커밋 메시지 목록이 전부 "feat: 페이지 추가"로 되어 있는 프로젝트도 보았습니다. 커밋 메시지 작성이 너무 어려워서 그냥 포기한 것입니다.

전통적인 커밋에 대해 이야기하기에는 아직 이릅니다#

제가 전통적인 커밋이 나쁘다고 말하는 것은 아닙니다. 이들은 여러 가지 잘 알려진 장점이 있습니다:

• 통일된 형식을 제공하여 커밋 메시지를 더 표준화합니다.
• 자동 도구가 파싱하기 쉬워서 자동 변경 로그 생성을 가능하게 합니다.
• 팀원들이 코드 변경의 목적과 범위를 이해하는 데 도움을 줍니다.
• 다양한 코드 변경 유형을 빠르게 식별할 수 있습니다.

그러나 전통적인 커밋을 사용한 후에도 여전히 좋은 커밋 메시지를 작성하는 데 어려움을 겪는 개발자에게는, 전통적인 커밋을 사용하는 방법에 관한 글을 던져주고, feat 유형이 무엇인지, fix 유형이 무엇인지 가르치는 것은 사실 무의미합니다. 이는 요리를 모르는 사람에게 고급 요리책을 주면서 기본 재료와 도구 사용하는 법을 가르치지 않는 것과 같습니다. 그런데도 이러한 글은 인터넷에 넘쳐납니다. 전통적인 커밋은 개발자가 명확한 사고를 하고 작업을 정확하게 나눌 수 있는 능력을 가질 때에만 진정으로 효과를 발휘할 수 있다는 것을 그들은 모릅니다.

그래서 전통적인 커밋이 나쁜 것은 아니지만, 그 전에 우리는 올바른 개발 마인드를 확립하고 과학적인 개발자 사고를 사용하여 일을 해결해야 합니다.

좋은 커밋 메시지를 위한 주요 사고법#

코드 변경은 한 번에 한 가지 일만 수행해야 합니다#

소프트웨어 개발에서 "한 번에 한 가지 일만 수행하기"는 중요한 원칙입니다. 이는 코드 작성뿐만 아니라 코드 커밋에도 적용됩니다. 우리가 특정 작업이나 변경에 집중할 때, 우리의 코드는 더 명료해지고 우리의 의도가 더 명확해집니다. 이 방법은 코드 가독성을 향상시킬 뿐만 아니라 코드 검토 과정을 크게 단순화합니다. 검토자는 각 변경의 목적을 더 쉽게 이해하고 확인할 수 있습니다.

더 나아가, 이 방법은 잠재적인 코드 롤백에 대한 편리함을 제공합니다. 문제가 발생하면 다른 관련 없는 부분에 영향을 미치지 않고 특정 변경 사항을 더 쉽게 찾아서 되돌릴 수 있습니다. 가장 중요한 것은, 각 변경이 한 가지 일만 수행할 때, 이 변경을 설명하는 커밋 메시지가 자연스럽고 더 정밀하며 의미 있게 됩니다.

실제로, 이는 우리가 코딩을 시작하기 전에 완료해야 할 작업을 명확하게 정의해야 함을 의미합니다. 작업이 완료되면 코드를 즉시 커밋해야 하며, 여러 작업이 완료될 때까지 기다리지 말고 커밋하십시오. 현재 작업을 완료하면서 다른 수정이 필요하다는 것을 발견하면, 최상의 방법은 이를 기록해 두었다가 현재 작업이 완료된 후 별도로 처리하는 것입니다. 예를 들어, 기능을 구현하는 중에 기존 버그를 발견한 경우, 지금 당장 새 기능 코드와 함께 버그를 수정하지 않고 먼저 기능을 구현한 후 감지된 버그를 다른 커밋에서 수정하거나 버그를 먼저 수정한 후 기능을 커밋하십시오.

커밋 메시지는 코딩을 시작하기 전부터 존재해야 합니다#

많은 개발자는 코드 완료 후에 커밋 메시지를 어떻게 작성할지 생각하기 시작합니다. 그러나 실제로 커밋 메시지는 우리가 코딩을 시작하기 전에 존재해야 합니다. 이는 커밋 메시지가 본질적으로 작업을 완료하기 위한 단계들을 반영하기 때문입니다. 즉, 이는 우리의 할일 목록입니다.

작업을 시작할 때, 이 작업을 완료하기 위해 필요한 구체적인 단계를 먼저 생각해야 합니다. 이러한 단계들이 우리의 할일 목록이고, 동시에 우리의 미래 커밋 메시지입니다. 이러한 할일 목록과 함께, 우리의 각 코드 변경은 목적을 가졌으며, 코딩 중에 집중력을 유지하고 작업에서 벗어나지 않도록 합니다.

더 중요하게는, 이 방법은 우리의 효율성을 크게 향상시킬 수 있습니다. 우리가 단계를 완료하면, 대응되는 커밋 메시지가 이미 준비되어 있으며, 이를 직접 사용할 수 있어 변경 사항을 설명하는 방법을 고민하는 데 시간을 절약할 수 있습니다. 동시에, 이러한 커밋 메시지는 우리가 작업에 대해 포괄적인 이해를 가질 때 작성되었기 때문에 대개 더 높은 품질과 정보를 제공합니다.

새로운 사용자 등록 기능을 구현해야 하는 경우, 작업 단계를 다음과 같이 계획할 수 있습니다:

1. 기존 폼 컴포넌트를 더 일반적이고 재사용 가능하게 리팩터링하기
2. 사용자 등록 폼 만들기
3. 사용자 등록을 위한 API 통합 구현하기
4. 사용자 등록 기능을 위한 유닛 테스트 추가하기
5. 사용자 등록 기능에 대한 문서 업데이트하기

이 작업 단계에 대응하는 커밋 메시지는 다음과 같을 것입니다:

1. refactor: 기존 폼 컴포넌트의 재사용성 향상
2. feat: 사용자 등록 폼 생성
3. feat: 사용자 등록 API 통합 구현
4. test: 사용자 등록 유닛 테스트 추가
5. docs: 사용자 등록 기능 문서 업데이트

이렇게 하면 코딩을 시작하기 전에 명확한 작업 단계와 이에 따른 간결한 커밋 메시지가 마련됩니다. 이러한 커밋 메시지는 사실 우리의 할일 목록으로, 전체적인 기능 구현 과정을 안내합니다.

각 단계를 완료할 때마다, 대응되는 커밋 메시지를 사용하여 코드를 커밋할 수 있습니다. 이는 작업을 더 잘 조직하고 실행할 수 있도록 도와줄 뿐만 아니라, 각 커밋이 특정 단계에 집중하게 하여 전체 개발 프로세스를 더 명확하고 관리 가능하게 만듭니다. 실제 코딩 중에 커밋 메시지를 약간 조정해야 할 경우, 실제 변경 사항을 더 정확하게 설명하기 위해 사소한 수정을 할 수 있습니다.

전통적인 커밋이 자연스러운 선택이 됩니다#

올바른 개발 마인드를 개발하면, 전통적인 커밋을 사용하는 것이 자연스러워집니다. 이 단계에서는 적절한 타입 접두사를 선택하는 것이 쉽습니다 (예: feat, fix, refactor 등), 왜냐하면 이미 커밋 메시지가 작업 단계를 명확하게 반영하고 있기 때문입니다.

전통적인 커밋 사용 방법에 대해 더 알고 싶다면, 온라인에 많은 훌륭한 글들이 있으니 참고해 보세요. 하지만 이런 규칙이 진정으로 효과적이기 위해서는 올바른 개발 마인드셋의 기초 위에 있어야 한다는 것을 기억하세요.

결론#

좋은 커밋 메시지를 작성하는 것은 단순히 특정 형식을 따르는 것만이 아닙니다. 이는 개발 과정에서 명확한 사고를 유지하고, 각 변경의 목적을 명확히 하며, 코딩을 시작하기 전에 우리의 작업을 어떻게 설명할지 고려하는 것이 필요합니다.

전통적인 커밋은 확실히 유용한 도구이지만, 올바른 개발 마인드셋과 결합될 때 최대 효과를 발휘할 수 있습니다. "한 번에 한 가지 일만 하기"와 "커밋 메시지를 미리 생각하기"라는 두 가지 원칙을 실천함으로써, 우리는 커밋 메시지의 품질을 향상시킬 수 있을 뿐만 아니라, 전체 개발 효율성과 코드 품질도 향상시킬 수 있습니다.

이 글이 당신의 개발 과정을 다시 생각해보고, 이러한 방법을 시도해보도록 격려하기를 바랍니다. 좋은 개발 습관은 시간이 걸리지만, 일단 형성되면 작업 효율성과 코드 품질을 크게 향상시킬 것입니다.