코드를 언제 커밋합니까?

프로젝트에서 작업 할 때 코드는 하루 또는 비트 단위로 몇 주 / 월 / 년의 기간 동안 합리적으로 빠르게 개발 될 수 있습니다. 코드 커밋이 프로젝트 개발의 척도로 간주됨에 따라 커밋이 적은 프로젝트보다 더 많은 코드가 작성되었음을 의미하지는 않습니다.

그렇다면 문제는 커밋을 정당화하기 위해 실제로 리포지토리에 커밋해야 할 시점입니다.

추가 기능으로 : 프로젝트 커밋을 기반으로 프로젝트 개발을 측정하는 것이 올바른 방법입니까?

기억하고 싶은 코드베이스 상태에 도달하면 커밋합니다. 특정 코드베이스 상태를 기억해야하는 이유는 여러 가지가 있으므로 커밋시기에 대한 엄격한 규칙을 적용 할 수 없습니다. 그러나 커밋 수는 확실히 품질이나 진행의 척도가 아닙니다.

저는이 맥락에서 코딩을 암벽 등반이라고 생각하고 싶습니다. 조금 올라가면 바위에 닻을 내립니다. 당신이 넘어지면, 당신이 심은 마지막 앵커가 당신을 확보하는 지점이므로, 당신은 몇 미터 이상 떨어지지 않을 것입니다. 소스 제어와 동일합니다. 약간 코딩하고 약간 안정적인 위치에 도달하면 개정을 커밋합니다. 당신이 끔찍하게 실패한다면, 당신은 항상 그 마지막 개정으로 돌아갈 수 있으며, 그것이 안정하다는 것을 알고 있습니다.

즉, 팀에서 일하는 경우 커밋하는 것이 완벽하고, 합리적이며, 깔끔하게 구축되며, 다른 사람의 것을 깨뜨리지 않는 것이 관례입니다. 다른 사람의 작업을 방해 할 수있는 더 큰 변경이 필요한 경우 다른 사람을 방해하지 않고 커밋 할 수있는 지점을 만드십시오.

또한 사용중인 SCM 시스템에 따라 다릅니다. 분산 시스템은 일반적으로 머지와 포크를 어렵지 않고 빠르게 만들며 로컬로 커밋 할 수 있습니다. 이것은 많은 양의 작업을 수행했을 때 많은 것을 커밋하고 푸시 / 병합해야한다는 것을 의미합니다. svn 또는 cvs와 같은 중앙 집중식 시스템을 사용하면 커밋이 비용이 많이 들고 모든 사람에게 영향을 미칩니다. 분기는이 문제를 부분적으로 해결하지만 서버에서 발생하기 때문에 고통이 느리고 병합이 번거로울 수 있습니다. 따라서 중앙 집중식 SCM을 사용하면 상당한 양의 작업을 한 번만 수행하면 더 신중한 문화가 형성됩니다.

부가 기능에 관해서 : 제발, 제발 그렇게하지 마십시오. 코드 라인, 커밋 수, 발견 / 해결 된 버그 수 등은 모두 품질 또는 수량을 매우 잘못 측정합니다.

Mercurial 또는 Git과 같은 DVCS를 사용하는 경우 상당한 양의 작업을 수행 할 때마다 로컬 저장소에 커밋해야합니다. 그러나 테스트 된 자체 포함 된 변경 사항이 작동 한 후에 만 ​​공유 저장소로 푸시하십시오.

비 분산 VCS (예 : SVN)의 경우 동일한 리포지토리가 로컬 리포지토리 대신 기본 분기로 푸시 병합 대신 프라이빗 브랜치를 사용합니다.

일찍 그리고 자주 커밋해야합니다.

나는 90 초마다 자주 헌신하는 사람들을 알고있다. 진심으로. 그들에게 효과가있는 것 같습니다. 파일을 저장할 때마다 커밋을 실험했습니다. 아마도 90 초 이상일 것입니다. 오늘은 약 15 분마다 커밋합니다. 여러 커밋을 하나로 커밋하고 로컬 커밋 (git과 같은)을 허용하는 VCS는이를 훨씬 쉽게 만듭니다.

얼마나 자주 커밋해야합니까? 말하기 어렵지만 지금보다 더 자주 나타납니다. 점점 더 자주 커밋하고, 너무 자주 느껴지는 지점을 찾은 다음 약간 뒤로 물러서십시오. 당신은 합리적인 무언가로 끝날 것입니다.

사용자에게 제공되는 가치를 기반으로 제품 개발을 측정합니다. 다른 정확한 측정은 없습니다.

커밋은 모든 버전 제어 데이터 / 코드의 빌딩 블록입니다. 각 커밋은 정확히 다음 중 하나를 수행해야합니다.

• 새로운 데이터 또는 기능 추가
• 수정이 가능한 곳에서 하나 이상의 버그 수정 (가능한 경우 각 수정에 대해 한 번의 커밋) :
  • 성능 향상
  • 잘못된 코드 동작 수정
  • 인쇄상의 오류 제거
• 의미를 변경하지 않고 코드 또는 데이터를 리팩토링합니다. 여기에는 다음이 포함됩니다.
  • 원본과 동일하게 동작하는 코드 재 작성
  • 데이터 표현을 다른 형식으로 변경
  • 프로젝트의 형식 지침에 맞게 코드 또는 데이터 형식
• 다른 지점 (업스트림 / 다운 스트림)에서 변경 사항 병합

또한 지점에서 작업 할 때 커밋은 더 적절한 지점으로 이동해야합니다. 두 커밋은 동일한 커밋 메시지를 가져서는 안되며 (유사한 변경 내용을 암시) 공동 작업자를 혼동하기 때문에 다른 브랜치에 있어야합니다. 더 좋은 방법은 메인 브랜치에 커밋하고 기능 브랜치에 병합하는 것입니다.

커미터가 위의 규칙을 따르는 경우 다음과 같이 간단합니다.

• 부작용없이 특정 변경 사항 되돌리기
• 코드 형식 변경에서 코드 변경을 변경하는 동작 식별
• 대부분의 충돌을 피하면서 서로 다른 브랜치간에 병합
• 변경 사항을 쉽게 풀 수있는 다른 개발자와 공동 작업

커밋을 기반으로 프로젝트 진행 상황을 측정하는 것과 관련하여 리팩토링 커밋 및 버그 수정 커밋이 고려되지 않을 수 있습니다.

주어진 기능 / 모듈 / 기능을 성공적으로 단위 테스트하고 통합 또는 시스템 테스트를 수행 할 준비가되었음을 확신하는 경우에만 커밋하십시오.

애드온 질문에 답하기 위해-아니요 !! 커밋의 수에 의해 프로젝트가 어디에서 이루어지지 않아야하는지에 대한 측정은 ... 누가 실제로 커밋되었는지 알고 있습니까? 시스템 테스트 또는 단위 테스트를 성공적으로 마쳤습니까? 커밋되었다고해서 프로덕션 준비가 된 것은 아닙니다.

추가 기능으로 : 프로젝트 커밋을 기반으로 프로젝트 개발을 측정하는 것이 올바른 방법입니까?

아니요 . 왜 그렇게 끔찍한 아이디어인지에 대한 WTF가 매일 있었습니다 .

코드 커밋에 대한 일반적인 경험 규칙은 코드 덩어리를 완료하고 컴파일 할 때 체크인하는 것입니다. 청크는 실제로 정의되지 않았습니다. 작은 작업 인 경우 완료 할 때까지 체크인하지 못할 수 있습니다. 더 큰 경우 각 논리 부분이 완료된 후 체크인 할 수 있습니다.

그러나 컴파일되지 않으면 체크인하지 마십시오. 실제로 큰 소리로 말하는 것은 어리석은 일인 것 같습니다만, 전에는 사람들에게 설명해야했습니다.

코드가 다른 코드 사용자와 공유 할 준비가되면, 코드가 상대적으로 안정적이고 안전하며 올바르게 테스트 된 경우 커밋합니다.

그리고 저는 커밋이 프로젝트 개발을위한 훌륭한 척도라고 생각하지 않습니다. 모든 소규모 및 소규모 변경을 커밋하는 개발자와 기능에 큰 변화 만 커밋하는 개발자를 알고 있기 때문입니다. 한 커밋의 가치를 다른 커밋보다 어떻게 정량적으로 측정합니까?

해당 작업이 완료 되 자마자 . 작업은 의 일부 사용자 스토리 .

작업이 완료 될 때 :

• 해당 단위 테스트 통과
• 코드가 올바르게 문서화되고
• 코드가 커밋됩니다.

done 의 다른 정의를 가질 수 있습니다 .

커밋 수를 측정하는 데 가치가 없습니다. 그러나 같은 사용자 스토리 (또는 더 나쁜 스토리)에서 누군가가 오랫동안 일하는 것을 본다면 이는 냄새입니다.

당신이 생각하지 않는 모든 중요한 변화를 저 지르십시오. 커밋하지 말아야 할 유일한 것은 스타일 변경은 논리의 변경을 구현하지 않기 때문입니다. 그러나 그렇지 않으면 변경 사항이 작을수록 커집니다.

커밋이 작을수록 더 나은 커밋 로그의 한 측면 인 사고 프로세스를 더 자세히 문서화 할 수 있습니다. 좋은 코드 검토는 코드 결과뿐만 아니라 사고 과정에 관한 것이어야합니다.

또한 작은 커밋이 많으면 버전 제어 기능이 너무 적게 사용되는 방법으로 쉽게 이분법을 만들 수 있습니다.이 기능은 건초 더미 코드베이스에서 바늘 버그를 찾는 데 많은 시간을 절약했습니다.

간단히 말해서 양분; 현재 코드베이스에서 문제를 발견하십시오. 그런 다음 특정 문제가 존재하지 않는 변경 로그에서 커밋을 선택하십시오. "양호한"버전과 "나쁜"버전 사이의 커밋을 확인하는 것으로 시작하십시오. 문제가 여전히 존재하는지 테스트하십시오. 그렇다면 "양호한"중간에 이전에 테스트 한 커밋을 다시 한 번 되돌아보아야합니다. 문제가 사라지면이 특정 변경 이후에 문제가 발생 했으므로 "나쁜"문제와 이전에 테스트 한 커밋 사이의 중간을 확인해야합니다. 반복. 결국 문제를 일으킨 커밋으로 끝납니다. 그러나 작은 커밋이있는 경우에만 문제가 발생하는 큰 변화 더미를 알 수 있습니다.

다음 은 Git에서 작동하는 방식이지만 주체는 모든 버전 관리에 적용됩니다.

언제:

• 그것은 (항상) 빌드
• 단위 테스트 통과
• 작동합니다 ( "진행 중"으로 명확하게 표시되지 않은 경우)
• 코드 상태를 저장하여 테스트를 실행하고 커밋 메시지를 잘 작성하고 커밋 프로세스 중 병합 충돌을 해결하는 번거 로움을 줄이는 이점