때때로 우리는 소프트웨어의 커밋 히스토리를 확인할 때 실제로 큰 커밋이 몇 개 있다는 것을 알 수 있습니다. 소스 코드 라인 (델타)이 수백 가지로 변경되어 10 개 또는 20 개의 파일이 변경 될 수 있습니다. BIG 커밋에 일반적으로 사용되는 용어가 있지만 그 용어가 무엇인지 정확하게 기억할 수는 없습니다. 누구든지 나를 도울 수 있습니까? 프로그래머가 일반적으로 그러한 큰 커밋과 거대한 커밋을 나타내는 용어는 무엇입니까?

BTW, 많은 변화를 함께 실천하는 것이 좋은 습관입니까?

업데이트 : 영감 토론에 감사합니다! 하지만 "코드 폭탄"은 내가 찾고있는 용어라고 생각합니다.

(1) Ben Collins-Sussman : "..." code bombs "즉, 누군가가 몇 달이 걸리는 거대한 새로운 기능을 갖춘 오픈 소스 프로젝트를 보게되면 어떻게해야합니까? 수천 줄의 코드? ... "

(2) Dan Fabulich : "코드 폭탄, 또는 : 큰 아이디어를 가진 초보자 ... 코드 폭탄 은 너무 커서 아무도 그것을 검토 할 수 없습니다."

(3) Google Summer of Code : 가이드 라인 : "일찍 커밋, 자주 커밋 ... 하루 종일 일하지 말고 모든 코드를 하나의 코드 폭탄으로 밀어 내십시오 . 대신 모든 커밋이 하나의 작업에만 포함되어야합니다. "로그 메시지에 요약되어야합니다."

(4) Jeff Atwood : "코드 폭탄 ... 규칙 # 30 : 어둡게 가지 마십시오 . ...

우리는 아마 그것을 나쁜 커밋 이라고 부릅니다 . :)

나쁜 연습

그리고 네, 그것은 일반적으로 나쁜 습관으로 간주됩니다 .

• 그것을 만들기 검토하기 어렵다 ,
• 그것을 만들기 어려운이의 원래 의도를 저지 쉽고 빠르게 파악 ,
• 그것을 만들기 어려운 명시 적 수정에 코드를 영향을 방법을 참조하거나 문제를 해결하기 위해 ,
• 그것을 만들기 (가)의 크기가 노이즈에 의한 커밋 경우 어려운 알고 다른 관련되지 않은 변경 사항 (예를 들면 작은 정리 또는 다른 작업)은 함께 보내지 OT.

허용되는 경우

그러나 큰 커밋이 완벽하게 허용되는 경우가 있습니다 . 예를 들어 :

• 때 나뭇 가지에 걸쳐 통합 ,
• 버전이없는 다른 코드베이스에서 새 소스 를 추가 할 때
• 큰 기능을 제자리에 교체 할 때 (변경의 다른 부분을 다루는 작은 커밋으로 분기에서 수행해야하지만 전체를 다시 병합하므로 점진적 인 개발에 대한 더 나은 창을 가질 수 있습니다 기능 및 문제가 발생할 수 있음),
• 많은 자손 클래스와 소비자 클래스에 영향을주는 API를 리팩토링 할 때

따라서 가능하면 "외과 적 공격"유형의 커밋을 선호합니다 (문제 추적기의 작업 ID에 연결)! 정당한 이유가 있다면 계속 진행하십시오.

그 외에도, 나는 실제로 알지 못하고 커밋에 대한 특별한 이름을 들었다고 생각하지 않습니다. 몬스터 커밋? 뚱뚱한 커밋?

업데이트 : David Cary의 답변은 "코드 폭탄" 이라는 용어 (가장 중요한 것은 Subversion의 최초 제작자 인 Collins-Sussman)를 사용하여 주목할만한 IT 행위자와 연결되어 있습니다. 그렇게 (지금까지 나는 자주 들었다고 말할 수는 없다).

BTW, 많은 변화를 함께 실천하는 것이 좋은 습관입니까?

글쎄, 오랫동안 변경 사항을 유지하고 다양한 기능과 버그 수정을 구현 한 다음 커밋하는 것이 좋습니다. 이는 큰 커밋이 발생할 수있는 한 가지 방법입니다.

이것이 일어날 수있는 또 다른 방법은 리팩토링이 널리 사용되는 기능의 서명을 변경 한 다음 모든 기능을 변경해야하는 경우입니다. 이것은 반드시 나쁘지는 않으며 개발자가 일부 임계 값을 초과 할까봐 코드 정리를 자제하기를 원하지 않습니다.

따라서 커밋에서 터치 된 파일 수를 보는 것보다 더 많은 것이 있습니다.

내가들은 용어는 "청춘 체크인" 입니다. 그리고 나는 그들의 팬이 아닙니다. 나는 프로젝트의 합리적인 단계에서 다른 것이 깨지지 않도록 작은 커밋을 좋아합니다. 큰 커밋은 일반적으로 그 일이 발생했을 때 잠시 동안 잔향하는 문제로 가득 차 있습니다.

내가 전화를 "전형적인 SVN 커밋" 또는 "내일 출시 하루 커밋이다"

SVN을 좋아하는 한 로컬 커밋을 수행 할 수 없다는 사실로 인해 꺼졌습니다.

편집 : 그들은 일반적으로 커밋 메시지에 "stuff"와 "beer"라는 단어가 있습니다.

다시 편집 : 나쁜 습관은 아니지만 많은 변경 사항을 커밋하는 것은 가능한 한 피해야합니다. 짧고 간결한 개정 / 커밋을 검토하는 것이 더 쉽다는 것을 알게되었습니다. (잘 작성된 커밋 메시지와 쌍을 이루었습니다. 나쁜 예는 이전 편집을 참조하십시오)

"뜨거운 김이 나는 코드". :-)

• 초기 커밋 -SVN에 던져진 개정 제어하에 있지 않은 프로젝트
• 리팩토링 -아키텍트는 클래스 이름을 Smurf Naming Convention에서 변경하거나 패키지 계층의 루트를 변경하는 것에 대한 훌륭한 아이디어를 가지고 있습니다.
• 코드 형식 -설계자는 코드 들여 쓰기를 4 칸에서 3 칸으로 변경하거나 줄 끝을 Unix에서 Windows로 (또는 되돌리기) 변경하기로 결정했습니다.
• 금요일 커밋 -Joe는 항상 금요일 주중 16:30에 일주일 내내 커밋합니다.
• uuups commit -Ted가 실수로 루트 디렉토리를 삭제하고 커밋 한 후 전체 파일 계층을 다시 SVN으로 펌핑합니다.

일반적으로 많은 사람들이 중앙 집중식 VCS를 사용하여 커밋을 많이하는 경향이 있습니다. 특히 서버는 적절한 커밋 정책을 시행합니다. 이는 커밋이 모든 테스트를 통과해야하며 테스트 시간이 더 오래 걸립니다 (몇 초 이상). 따라서 개발자는 여러 번 커밋하고 변경 사항을 여러 개의 작은 커밋으로 나누기 위해 너무 오래 기다리기를 원하지 않습니다.

또한 VCS에 익숙한 개발자는 변경 사항을 여러 개의 작은 커밋으로 나누는 것을 잊을 수 있습니다. 품질 보증팀에 프로그램을 출시 할 때만 커밋해야합니다. 더 나쁜 것은 다른 사람들이 버그가있는 코드를 보지 못하도록하기 위해 QA 테스트를 통과하기 전에 커밋하지 않는 것입니다. 마지막으로, 출력 바이너리, 임시 파일 및 링커 출력을 커밋하여 실제로 "큰"커밋을 생성 한 것을 알지 못했습니다.