버전 관리 시스템에서 유지 관리하는 커밋 기록을 사용하는 데 드는 비용은 거의 없습니다. 그러나 주요 프로젝트 리팩토링 (또는 재구성 / 정리) 노력 중에는 함수와 클래스 및 네임 스페이스가 이동합니다. 때때로 여러 파일이 병합되고 다른 파일이 분할됩니다. 이러한 변경으로 인해 일부 파일의 원래 커밋 기록이 손실 될 수 있습니다.
제 개인적으로는 프로젝트 구성을 유지하는 것이 소스 코드 기록을 유지하는 것보다 중요합니다. 좋은 프로젝트 구성을 통해 합리적인 노력으로 새로운 기능을 지속적으로 추가 할 수 있으며 소스 코드 히스토리의 가치는 모호한 것으로 보입니다.
또한 단위 테스트를 사용하여 회귀 문제를 신속하게 식별 할 수 있습니다. 최신 버전이 모든 소프트웨어 요구 사항을 계속 충족하는 한 실제로 소스 코드의 기록을 보존해야합니까?
고객은 주요 버전 업그레이드를 수행 할 필요없이 고객에게 지원을 제공 할 필요가 있기 때문에 제공된 소스 코드를 보존해야 한다는 것을 이해합니다 . 그러나이 외에도 소스 코드 커밋의 이력을 유지하는 데 어떤 가치가 있습니까?
소스 코드 커밋 히스토리가 팀 구성원 간의 커뮤니케이션에서 어떤 역할을합니까? 커밋 히스토리를 폐지하는 대신 통신을 위해 "소스 코드"+ "단위 테스트 코드"에 의존한다면 어떨까요?
커밋 히스토리가 존재하면 주요 설계 / 요구 사항 변경 및 이러한 변경을 유발 한 사고의 흐름과 같은 프로젝트에 대한 중요한 정보의 장기 문서화에 만족 하는가?
3
어떤 소스 코드 시스템을 사용 하느냐에 따라 파일 히스토리 및 기타 정보가 있더라도 버전 기록이 보존됩니다. 삭제 된 파일의 히스토리에도 여전히 액세스 할 수 있어야합니다. 그리고 마지막으로 중요한 것은 최종 결과의 역사입니다. 클래스 X는 클래스 Y와 Z의 조합 일 수 있지만 기록에 따르면 (특히 체크인 주석이있는 경우) 원본을 다시 추적 할 수 있습니다. 여기에 뭔가 빠졌습니까?
—
Adam Lear
These changes often lead to the loss of the original commit history of a few files.예를 들어 "git blame"을 보라-아무것도 잃어 버리지 않는다. 때로는 찾기가 조금 어려울 수 있지만 항상 있습니다.
대규모 리팩토링에서는 소스 제어 업데이트를 생각하고 계획하는 데 약간의 시간이 걸립니다. 최소한의 추가 노력으로 더 많은 정보를 보존 할 수 있습니다. 예를 들어, 파일을 3 조각으로 분할 한 경우 먼저 원본을 3 개의 대체물로 복사 한 사본을 보존하십시오. 다음 더 커밋 세 ... 수정
—
UuDdLrLrSs