버전 관리에 관해서는 큰 커밋보다는 작고 집중적인 커밋을 많이 만드는 것을 옹호합니다.
그리고 제가 살아있는 동안 지구에 작은 변화를 만들어 보겠습니다.
— 겁먹은 토끼
커밋을 작게 만드는 것이 아니라 집중적이고 목적이 있는 커밋을 만드는 것이 목표입니다. 각 커밋은 코드베이스에 대한 하나의 논리적 변경 사항을 나타내야 합니다.
결국 동일한 변화에 도달할 수 있지만 작은 커밋은 시간을 관리하고 작업을 올바르게 완료하는 동시에 미래를 위한 유용한 정보를 남기는 데 도움이 됩니다.
대규모 프로젝트를 작은 작업으로 나누세요. 이는 시간을 잘 활용하고 성공적인 결과를 생성하는 데 중요한 부분인 전통적인 프로젝트 관리 기술입니다. 파킨슨의 법칙은 할당된 시간을 채우기 위해 작업을 확장하므로 더 많은 작은 작업을 식별할 수 있으면 시간 변동을 제한하는 데 도움이 된다고 제안합니다.
작업이 어떻게 설명적인 커밋 메시지로 변환되는지 생각해 보세요. 작업이나 메시지가 겹치거나 유사한 경우 해당 작업을 병합할 수 있나요? 그렇지 않은 경우 주요 차이점을 식별하여 구별하십시오. 프로 팁: 커밋 메시지에 "and"라는 단어가 나타나거나 설명하는 데 여러 문장이 필요한 경우 커밋을 분할해야 합니다.
커밋이 프로젝트를 작동 상태로 유지하는지 확인하세요. 항상 가능하지는 않지만, 이 지침은 여러 개발자가 단일 저장소에서 작업할 때 정말 도움이 됩니다. 프로젝트 기능을 종료하면 분기를 더 자주 생성 및 병합하고 충돌을 제한할 수 있습니다. 그리고 변경 사항을 롤백해야 하는 경우 애플리케이션 기능을 그대로 유지할 가능성이 높습니다.
커밋하기 전에 변경 사항을 검토하여 집중하세요. 때때로 우리는 기회주의적인 변화를 발견하거나 주요 임무를 망각합니다. 이러한 통찰력과 업데이트를 잃고 싶지 않지만 버전 제어 도구 및 IDE의 변경 사항을 격리하여 커밋을 구별할 수 있는 여러 가지 방법이 있습니다.
커밋 수가 증가하면 커밋을 의미 있게 유지하기가 어려울 수 있습니다. 명확성과 일관성을 위해 기존 커밋과 같은 스타일을 채택하는 것을 고려해 보세요.
소규모 커밋의 이점은 다음과 같은 여러 주요 영역에서 분명해집니다.
작고 집중적인 커밋은 이해하고 검증하기가 더 쉽습니다. 검토자는 다양한 커밋을 개별적으로 살펴보고 각각의 작은 작업 단위에 대한 관련 세부 정보에 집중할 수 있습니다.
커밋이 작을수록 검토자가 피로할 위험이 줄어들고 전반적인 품질이 높아집니다.
프로그래머에게 코드 10줄을 검토하라고 하면 10가지 문제를 발견하게 됩니다. 500줄 해달라고 하면 괜찮다고 하더군요.
– 기라이 외질
<script> // Detect dark theme var iframe = document.getElementById('tweet-306836785739210752-603'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=306836785739210752&theme=dark" } </script>
작은 커밋을 통해 문제가 발생한 위치를 더 쉽게 식별할 수 있습니다. 세분화된 커밋을 사용하면 git bisect와 같은 도구를 보다 효과적으로 사용하여 문제를 정확히 찾아낼 수 있습니다. 결함이 식별되면 소규모 커밋을 통해 기존 코드 변경에 따른 위험과 테스트 범위를 제한할 수 있습니다.
각 커밋은 단일 변경 사항에 대한 스토리를 전달해야 합니다. 커밋이 작을수록 그 이야기는 자신을 포함한 미래의 개발자에게 더 명확하고 의미가 커집니다.
프로젝트 기간이 늘어남에 따라 커밋 기록을 통해 선택한 경로와 포기한 경로, 해결된 오류 및 알아야 할 위험에 대해 알 수 있습니다. 커밋 메시지가 더 좋고 구체적일수록 프로젝트 이력을 이해하기가 더 쉽습니다.
커밋이 작으면 변경 사항이 중복되어 병합 충돌이 발생할 위험이 줄어들 뿐만 아니라 변경 사항이 작아도 충돌을 해결하기가 더 쉽습니다.
앞서 언급했듯이 문제가 발생하는 경우 작은 커밋을 롤백하는 것이 상호 연결된 대규모 변경 사항을 실행 취소하는 것보다 덜 위험합니다.
커밋되지 않은 코드는 저장되지 않은 문서가 있는 것과 같습니다. 코드 줄을 수정하고 체크인하는 데 시간이 더 많이 걸릴수록 해당 변경 사항을 잃을 가능성이 더 커집니다. 실수로 삭제; 덮어쓰기; 분기를 전환하기 전에 변경 사항을 숨기지 못했습니다. 파일 대신 브랜치를 재설정하면...작업 내용이 손실될 수 있는 방법이 많습니다.
Git과 같은 최신 버전 관리를 사용하면 분기가 사실상 무료입니다. git stash는 긴급 상황에서 유용할 수 있지만 기능이나 유지 관리 브랜치에 병합할 수 있는 임시 브랜치를 생성하는 데에도 거의 동일한 노력이 필요합니다.
커밋된 변경 사항은 서버에 있는 저장소의 분기나 포크로 푸시될 수 있으므로 다른 사람들이 이를 공동으로 보고 작업할 수 있으며 로케일 시스템이 작업 비용을 초래할 수 있는 단일 실패 지점이 되지 않도록 할 수 있습니다.
기능 브랜치에서 여러 개의 작은 커밋을 생성하는 경우 코드 검토 중에 매우 유용한 개별 기록을 잃지 않도록 풀 요청을 사용하여 마지막에 이를 단일 커밋으로 압축하는 것이 바람직할 수 있습니다.
저는 기록을 유지하는 것을 선호하지만 병합의 범위와 빈도에 따라 다릅니다.
결국 모든 작은 변경 사항을 표시할 필요는 없지만 커밋이 leitmotif(하나의 중요한 테마)를 공유하지 않는 경우에는 커밋하면 안 됩니다. 함께.
이는 Cleaner History 혜택과 연결됩니다. 작업이 진행되는 동안 이러한 별도의 메시지를 통해 코드 검토에서 실수나 불일치를 더 쉽게 발견할 수 있습니다.
refactor: JIRA-12345 - Replace guards with optional chaining refactor: JIRA-12354 - Replace logical OR with nullish coalescing
작업이 검증되고 병합할 준비가 되면 단일 압축 커밋으로 작업을 나타낼 수 있습니다.
refactor: JIRA-12345 - ES2020 update
브랜치에 다수의 리팩터링 커밋이 포함된 경우 프로젝트에 대한 추가 작업을 수행하기 전에 해당 커밋을 병합하고 압축하는 것을 고려하세요. 이를 통해 리팩토링이 프로젝트 작업과 별도로 유지되면서 더 넓은 기록에서 단일 커밋으로 표시될 수 있습니다.
이는 다양한 작업의 위험을 별도의 기록 항목으로 더욱 격리하고 브랜치 수명을 단축시키므로
스타일에 익숙하지 않으면 익숙해지는 데 시간이 걸릴 수 있지만 작은 커밋이 코드 품질과 개발 프로세스를 개선하는 데 도움이 될 수 있습니다.
더 작은 규모의 커밋을 만드는 연습을 하세요. 거의 모든 버전 관리와 마찬가지로 오늘 작업에 대한 보상은 나중에 자신과 다른 사람에게 이익이 되지만 그 날은 예상보다 빨리 올 수 있습니다.
위 내용은 작은 커밋을 해보세요의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
