소스 컨트롤에 변경 사항을 커밋하는 빈도는? [닫은]

얼마나 자주 소스 제어 변경 사항을 커밋해야합니까? 모든 작은 기능 이후 또는 큰 기능에만 적용됩니까?

프로젝트를 진행 중이며 장기적으로 구현할 기능이 있습니다. 현재, 나는 모든 작업 덩어리, 즉 모든 하위 기능이 구현되고 버그가 수정 된 후에 커밋하고 있습니다. 버그를 발견 한 후 일부 기능에 대한 새로운 테스트 덩어리를 추가 한 후에도 커밋합니다.

그러나이 패턴이 걱정됩니다. 생산적인 작업 일에 10 번 커밋을 할 수 있습니다. Subversion을 사용하고 있다고 가정하면 이러한 커밋은 전체 저장소에 영향을 미치므로 실제로 많은 것을 만드는 것이 좋은 방법인지 궁금합니다.

컴파일하고 실행하는 코드의 "완전한 생각"을 완료 할 때마다 체크인합니다. 일반적으로 15-60 분 사이입니다. 때로는 더 길어질 수 있지만 실패 할 때 다시 작성하고 싶지 않은 많은 코드 변경 사항이 있으면 항상 체크인하려고합니다. 또한 일반적으로 코드가 컴파일되고 집에 가기 전에 근무일이 끝날 때 체크인합니다.

"너무 많은"커밋 / 체크인을 걱정할 필요가 없습니다. 무언가를 다시 써야 할 때 정말 짜증납니다. 경우에 따라 조금씩 롤백 할 수있어서 좋습니다.

"커밋이 전체 리포지토리에 영향을 준다"고 우려하는 경우 --- 전체 리포지토리의 개정 번호가 증가한다는 사실을 언급하고 있습니까? Subversion이 저장하는 데 사용하는 비트 수를 모르지만 개정 번호가 부족하지 않을 것이라고 확신합니다! 많은 커밋은 문제가되지 않습니다. 당신은 옆집 사람보다 10 배 자주 커밋 할 수 있으며 탄소 발자국을 전혀 늘리지 않을 것입니다.

하나의 함수 또는 메소드의 이름을 지정해야하며 이름이 너무 길면 너무 많이 수행됩니다. 체크인에 동일한 규칙을 적용하려고합니다. 체크인 주석은 변경 내용을 정확하게 설명해야하며 주석이 너무 길면 한 번에 너무 많이 변경 될 수 있습니다.

나는 Jeff Atwood의이 작은 기사를 좋아한다 : 일찍 체크인, 종종 체크인

나는 개인적으로 완료 / 안정 / 컴파일 된 모든 논리적 코드 그룹을 커밋하고 그날 내가 한 일을 저 지르지 않고 하루를 떠나지 않으려 고 노력합니다.

주요 변경 사항을 작성 중이고 코드 작업을하는 다른 사람에게 영향을 줄 우려가있는 경우 새 분기를 만든 다음 변경이 완료된 후 트렁크로 다시 병합 할 수 있습니다.

나는 작업이 끝날 때마다 커밋합니다. 보통 30 분에서 1 시간이 걸립니다.

버전 관리 설명이 한두 문장보다 긴 경우에는 자주 커밋하지 않을 수 있습니다.

나는 오픈 소스 만트라 (낙서)를 따르십시오-일찍 커밋하고 자주 커밋하십시오.

기본적으로 다른 팀 구성원에게 문제를 일으키지 않고 유용한 기능을 추가했다고 생각할 때마다 (그러나 작지만)

이 확약 전략은 다른 개발 노력에 대한 통합 테스트를 허용하여 문제를 조기에 발견 할 수 있으므로 지속적인 통합 환경에서 특히 유용합니다.

실제로 작동하지 않는 코드를 커밋하지 마십시오. 저장소를 백업 솔루션으로 사용하지 마십시오.

대신 불완전한 코드를 자동으로 로컬로 백업하십시오. Time Machine이 나를 돌보고 다른 플랫폼을위한 많은 무료 프로그램이 있습니다.

내가 사용하는 경험의 규칙은 체크인되는 파일 그룹이 단일 체크인 주석으로 처리 될 수있는 경우 체크인입니다.

이것은 일반적으로 체크인이 원 자성이고 다른 개발자가 주석을 쉽게 요약 할 수 있도록하기위한 것입니다.

변경 사항이 애플리케이션 범위가있는 구성 파일 (예 : 스프링 컨텍스트 파일 또는 스트럿 구성 파일)에 영향을주는 경우에 특히 그렇습니다. 체크인하기 전에 여러 '그룹'을 변경하면 구성 파일에 영향이 겹치므로 두 그룹이 서로 병합됩니다.

얼마나 자주 걱정해야한다고 생각하지 않습니다. 여기서 중요한 것은 무엇을 언제, 왜하는 것입니다. 3 시간마다 또는 24 시간마다 커밋해야한다고 말하는 것은 의미가 없습니다. 커밋해야 할 것이 있으면 커밋하지 마십시오.

다음 은 버전 관리를위한 권장 모범 사례 에서 발췌 한 내용입니다 .

[...] 동시에 프로젝트를 많이 변경하는 경우 논리적 부분으로 나누고 여러 세션에서 커밋하십시오. 따라서 개별 변경 기록을 훨씬 쉽게 추적 할 수 있으므로 나중에 버그를 찾아 수정하려고 할 때 많은 시간을 절약 할 수 있습니다. 예를 들어, 기능 A, B 및 C를 구현하고 버그 1, 2 및 3을 수정하는 경우 각 기능 및 버그마다 총 6 개의 커밋이 발생합니다. 큰 기능을 사용하거나 광범위한 리팩토링을 수행하는 경우 작업을 더 작은 부분으로 나누고 각 부분이 완료된 후에 커밋을 고려하십시오. 또한 여러 논리 모듈에 대한 독립적 인 변경을 구현할 때 더 큰 변경의 일부인 경우에도 각 모듈에 대한 변경을 커밋합니다.

이상적으로는 하드 드라이브를 커밋하지 않은 상태로 사무실을 떠나서는 안됩니다. 변경 사항이 다른 사람에게 영향을 미치는 프로젝트에서 작업하는 경우 분기를 사용하여 변경 사항을 구현하고 완료되면 트렁크로 다시 병합하십시오. 다른 프로젝트와 다른 사람들이 의존하는 라이브러리 나 프로젝트에 변경 사항을 커밋 할 때는 컴파일되지 않는 코드를 커밋하여 빌드를 중단하지 않아야합니다. 그러나 컴파일되지 않는 코드를 갖는 것이 커밋을 피하는 변명이 아닙니다. 대신 가지를 사용하십시오. [...]

현재 패턴이 의미가 있습니다. 이 소스 컨트롤 을 사용 하는 방법을 명심하십시오 . 롤백해야하거나 diff를 수행하려면 어떻게해야합니까? 설명하는 청크는 이러한 경우에 정확히 올바른 차이처럼 보입니다. diff는 버그 # (체크인 로그에 지정) 구현시 변경된 사항 또는 기능을 구현하기위한 새 코드가 정확히 무엇인지 표시합니다. 마찬가지로 롤백은 한 번에 하나만 터치합니다.

나는 또한 종종 하루에 여러 번 일하는 덩어리를 마친 후에 커밋하고 싶습니다. 큰 커밋보다 작은 커밋에서 일어나는 일을 확인하는 것이 더 쉽다고 생각합니다. 너무 많은 커밋이 걱정되는 경우 전체 기능이 완료되면 브랜치를 만들고 트렁크로 다시 병합하는 것을 고려할 수 있습니다.

관련 블로그 게시물은 다음과 같습니다. 코딩 공포 : 체크인 일찍, 자주 체크인

다른 사람들이 말했듯이, 다른 개발자의 방식으로 얻을 수 없을 정도로 충분히 "완전한"논리 청크를 한 가지 시도하십시오 (예 : 자동화 된 테스트를 빌드하고 통과 함).

각 개발 팀 / 회사는 각 지점에 대해 "충분한"항목을 정의해야합니다. 예를 들어, 코드 만 빌드하면되는 기능 분기, 자동화 된 테스트를 통과하기 위해 코드가 필요한 트렁크 및 QA 테스트를 통과 한 레이블 등이있을 수 있습니다.

나는 이것이 따라야 할 좋은 패턴이라고 말하지는 않는다. "완료"가 수행되는 방식은 팀 / 회사의 정책에 따라 달라집니다.

당신이 그것에 대해 생각하는 순간.

(체크인이 안전하다면)

소스 코드 시스템과 다른 시스템에 따라 다릅니다. Git을 사용하는 경우 단계를 마칠 때마다 커밋하십시오. SVN을 사용하고 전체 기능을 완료 할 때마다 1-5 시간마다 커밋하고 싶습니다. CVS를 사용하는 경우에도 동일한 작업을 수행합니다.

몇 가지 응답에 동의합니다. 컴파일되지 않는 코드를 체크인하지 마십시오. 우려되는 코드의 "백업"또는 변경 사항이있는 경우 개인 브랜치 또는 저장소를 사용하십시오. 논리 장치가 완료되면 체크인하십시오.

추가해야 할 또 다른 사항은 환경에 따라 체크인 속도가 시간에 따라 달라질 수 있다는 것입니다. 예를 들어, 구성 요소의 각 기능 부분이 완료된 후 프로젝트 체크인 초기에 안전과 개정 이력이 모두 의미가 있습니다 (나중에 비트가 개발 될 때 이전 비트가 리팩토링되는 경우를 생각합니다). 반면에 프로젝트에서, 특히 통합 개발 / 테스트 중에는 완전한 기능이 더욱 중요해집니다. 반 통합 또는 반 수정은 누구에게도 도움이되지 않습니다.

각 버그 수정 후 체크인에 관한 사항 : 수정이 사소한 경우가 아니면 절대적으로! 한 번의 체크인에 세 가지 수정 사항이 포함되어 있고 그 중 하나를 롤백해야한다는 것을 아는 것보다 더 큰 어려움은 없습니다. 종종 그 상황에서 개발자는 한 영역에서 3 개의 버그를 수정하고 어떤 버그 수정이 악몽인지에 대한 변화를 푸는 것으로 보입니다.

또한 정기적으로 체크인하고 싶습니다. 그것은 내가 목표를 향한 단계를 완료 할 때마다입니다.

이것은 일반적으로 몇 시간마다입니다 .

내 어려움은 너무 많은 코드 검토 를 기꺼이 수행 할 수있는 사람을 찾는 것 입니다.

우리 회사의 정책은 무엇이든 체크인하기 전에 코드 검토가 필요하다는 것입니다. 이는 의미가 있지만 부서에 코드 검토를 즉시 수행 할 시간이있는 사람이 항상있는 것은 아닙니다. 가능한 해결책:

1. 체크인 당 더 많은 일; 적은 체크인 == 적은 리뷰.
2. 회사 체크인 정책을 변경하십시오. 방금 리팩토링을 수행했는데 단위 테스트가 모두 녹색으로 실행되면 규칙을 완화 할 수 있습니까?
3. 누군가 검토를 수행하고 작업을 계속할 수있을 때까지 변경 사항을 보류하십시오. 검토자가 코딩을 좋아하지 않고 다시 디자인해야하는 경우 문제가 될 수 있습니다. 변경을 '선반'하여 작업의 다른 단계를 저글링하는 것은 지저분해질 수 있습니다.

나는 깔끔하게 컴파일되고 단위 테스트에 회귀가 없다면 30-60 분마다 변경 사항을 커밋합니다.

글쎄, 당신은 당신이 원하는만큼 커밋 할 수있는 자신의 지점을 가질 수 있으며, 기능을 마쳤을 때 주요 트렁크에 병합 할 수 있습니다.

커밋의 빈도로, 나는 이것을 이렇게 생각합니다. 하드 디스크가 고장 나서 무언가를 저지른 적이 없다면 얼마나 고통 스러울까요?

물론 컴파일하지 않는 것을 커밋하지 않습니다.

적어도 하루에 한 번.

커밋 당 특정 시간 제한이 없으며 테스트가 끝나면 커밋하는 경향이 있으며 코드에 만족합니다. 컴파일하지 않거나 실패 할 경우 되돌릴 생각이없는 상태의 코드를 커밋하지 않습니다.

한편으로는 안전성과 복구 가능성 사이의 타협과 다른 한편으로는 전체 프로젝트에 대한 변경 관리가 용이해야합니다.

내가 사용한 최고의 계획에는 그 질문에 대한 두 가지 대답이 있습니다.

우리는 2 개의 완전히 분리 된 저장소를 사용했습니다. 하나는 프로젝트 전체 저장소이고 다른 하나는 우리 자신의 개인 저장소였습니다 (당시 rc를 사용하고있었습니다).

열린 파일을 저장할 때마다 거의 정기적으로 개인 저장소를 체크인합니다. 따라서 개인 저장소는 기본적으로 크고 긴 범위의 실행 취소 버퍼였습니다.

우리가 컴파일하고 괜찮은 테스트를 한 코드 덩어리가 생겼을 때 일반적으로 사용할 준비가 된 것으로 받아 들여지면 프로젝트 저장소에 체크인되었습니다.

불행히도이 시스템은 다른 VCS 기술을 사용하여 작동 할 수있었습니다. 동일한 유형의 VCS 2 개 (예 : 2 개의 서브 버전 리포지토리)를 사용하면서 동일한 결과를 얻는 만족스러운 방법을 찾지 못했습니다

그러나 서브 버전 저장소에 "개인"개발 브랜치를 생성하여 정기적으로 브랜치를 체크인 한 다음 완료시 트렁크에 병합함으로써 적절한 결과를 얻었습니다.

릴리스되지 않는 지점에서 작업하는 경우 커밋은 항상 안전합니다.

그러나 다른 개발자와 공유하는 경우 작동하지 않는 코드를 커밋하는 것은 다소 성가신 일입니다 (특히 중요한 장소에있는 경우). 일반적으로 나는 효과적으로 "작동 중"인 코드 만 커밋합니다. 완전히 테스트 된 것이 아니라 실제로 컴파일되고 즉시 실패하지 않는지 확인했습니다.

통합 버그 추적기를 사용하는 경우 두 개의 버그를 수정 한 경우 커밋 로그가 올바른 버그에 대해 갈 수 있도록 별도의 커밋을 수행하는 것이 도움이 될 수 있습니다. 그러나 다시 한 번, 한 번의 코드 변경으로 두 개의 버그가 수정되므로 시스템에서 한 번의 커밋을 여러 개의 버그와 연관시키지 않는 한 어떤 버그를 선택해야 하는지를 선택해야합니다.

나는 여전히 '커밋하고 자주 커밋하라'라는 문구를 믿습니다. Mercurial 과 같은 분산 형 VCS를 선호 하며 몇 가지 사항을 커밋하고 나중에 업스트림으로 밀어 넣는 데 아무런 문제가 없습니다.

이것은 실제로 일반적인 질문이지만 실제 질문은 다음과 같습니다. 완료되지 않은 코드를 커밋 할 수 있습니까?

작동하는 일부 코드를 마칠 때마다 업데이트로 다른 사람을 망치지 않습니다.

그리고 당신이 제대로 언급했는지 확인하십시오.