대규모 작업에 적합한 소스 제어 체크인 전략은 무엇입니까?

일반적인 규칙은 체크인을 작게 유지하고 자주 체크인하는 것입니다. 그러나 때로는 작업이 기본 프레임 워크를 크게 변경해야합니다. 그런 다음 작업을 완료하기 전에 체크인하면 완료된 작업을 체크인 할 때까지 프로젝트가 중단됩니다.

따라서 사람들이 일을 잃거나 자신이하고있는 일을 결정하는 위험을 줄이기 위해 사람들이 사용하는 전략은 잘못된 접근법입니다. 그런 다음 코드를 제거하고 다른 접근법을 시도한 후 마음을 바꾸는 것입니까?

내가 할 수있을 때, 절반은 작업을 주석 처리하거나 컴파일하고 새 파일을 사용하는 것이 없으면 체크인합니다. 변경이 클수록 프로젝트를 분기 한 다음 다시 병합 할 가능성이 큽니다. 모든 것이 다시 작동 할 때 소스 제어 시스템이 허용하는 또 다른 옵션은 기본적으로 작은 가지 인 선반 세트입니다. 따라서 하루를 마치거나 의사 결정 지점에 올 때 변경 사항을 보류 한 다음 치명적인 일이 발생하거나 그 시점으로 돌아가고 싶습니다.

나는 자식을 사용하므로 대답은 "branch"입니다. 다양한 비트를 완료하면 분기 및 커밋 조각 식사.

행복하면 커밋을 업스트림으로 밀어서 동료가 트렁크를 방해하지 않고 변경 사항을 검토 할 수 있습니다.

모든 사람이 코드에 만족하면 병합하면 완료됩니다.

(상대적으로 오래 실행되는 지점에 대해하는 일은 주기적으로 트렁크 (git 용어의 마스터)를 지점으로 병합하므로 두 지점이 과도하게 분기되지 않습니다.)

대답은 사용중인 버전 제어 시스템의 종류에 따라 중앙 집중식 (예 : 서브 버전) 또는 분산 (예 : git)에 따라 달라질 것이라고 생각합니다. 분산 소스 제어 시스템 사용에 대한 실제 경험이 없으므로 내 답변은 우리가 서브 버전으로하는 일을 기반으로합니다.

시간이 지남에 따라 트렁크 빌드가 중단되거나 다른 방식으로 팀의 나머지 부분을 실제로 방해 할 큰 변화가 진행되는 경우 지점을 만듭니다. 나는 당신이 그렇게하지 않도록 최대한 많이해야한다고 말하고 싶습니다. 대부분의 변경은 약간의 노력으로 나머지 코드와 나란히 앉을 수 있습니다. 예를 들어 새 코드로 코드 경로를 트리거 할 수 있습니다 (간단한 if 문을 사용하거나 DI 프레임 워크를 사용하는 경우 구성 설정에 따라 새 버전을 삽입 할 수 있음). 그런 다음 구성을 새 버전으로 변경하고 모든 것을 테스트하고 사용하지 않는 코드를 삭제 한 후 다시 테스트하고 구성 설정을 삭제하십시오. 항상 그렇게 할 수는 없지만 지점을 유지 관리하는 오버 헤드로 인해 가능한지 항상 확인해야한다고 생각합니다.

지점을 운영하는 경우 사람들이 자주 본 실수는 트렁크로 지점을 최신 상태로 유지하지 않는 것입니다. 트렁크에서 브랜치로 변경 사항을 지속적으로 병합해야합니다. 그러면 트렁크의 모든 지점을 다시 병합하는 것이 매우 간단합니다.

out 팀에서는 subversion을 사용하며 일반적으로 작은 변경 사항을 트렁크에 직접 커밋합니다. 더 큰 작업의 경우, 작업을 수행하는 개발자는 일반적으로 개인 브랜치를 생성합니다. 개인 브랜치는 일단 완료되면 트렁크에 병합됩니다. 그런 다음 개인 브랜치가 삭제됩니다. 당연히 개인 지점이 있지만 소유자는 자주 확인해야합니다.

우리는 장기적인 브랜치와 트렁크 간 브랜치 병합을 피하려고 노력합니다. 왜냐하면 신중한 부기가 필요하기 때문입니다. 대신 우리는 한 번만 트렁크로 다시 병합되고 곧 삭제되는 비교적 짧은 지점을 가지고 있습니다.

그리고 최소한 한 사람이 변경 사항을 검토하고 승인 할 때까지 트렁크에 커밋하거나 병합 할 수있는 규칙이 없습니다.

SQL 서버 사용자의 일반적인 의견과 마찬가지로 "의존"

가능하다면 코드에 분기를 작성하여 작업의 작은 체크인을 계속 적용 할 것을 제안합니다. 완료되면 주 트렁크로 병합을 다시 수행하십시오.

그렇습니다. 노력이 중복 될 가능성이 있습니다. 그러나 최소한 당신은 롤백 할 수있는 일의 흔적을 maintian에게 줄 것입니다.