중앙 집중식 버전 관리에서 항상 자주 업데이트하는 것이 좋습니까?

가정 :

• 팀에서 중앙 집중식 버전 관리를 사용하고 있습니다.
• 완료하는 데 며칠이 걸리는 더 큰 기능을 작업 중이며 빌드를 중단 할 수 있기 때문에 그 전에 커밋 할 수 없습니다.
• 팀원은 매일 작업중인 일부 파일을 변경할 수있는 무언가를 커밋합니다.

이 기능은 중앙 집중식 버전 제어이므로 새로운 기능을 커밋하기 직전에 한 번 이상 로컬 체크 아웃을 업데이트해야합니다.

커밋 직전에 한 번만 업데이트하면 팀원의 많은 다른 변경으로 인해 많은 충돌이 발생할 수 있습니다. 이로 인해 한 번에 모든 문제를 해결할 수 있습니다.

또는 자주 업데이트 할 수 있으며 매일 해결해야 할 충돌이 몇 개 있더라도 조금씩 수행하기가 더 쉬워야합니다.

항상 자주 업데이트하는 것이 좋습니다?

개인적으로 로컬 버전을 매일 업데이트합니다.

당신이 묘사 한 시나리오에서, 나는 여분의 마일을

• 새롭고 긴 기능에 대한 분기 만들기
• 종종 메인 라인에서이 새로운 브랜치로 병합하십시오.

이 방법,

• 매일 체크인하여 서버에서 코드를 보존 할 수 있습니다
• 체크인하여 빌드를 깨는 것에 대해 걱정할 필요가 없습니다.
• 이전 체크인시 필요할 때 저장소를 사용하여 일부 작업 또는 diff를 취소 할 수 있습니다.
• 최신 코드베이스로 작업하고 충돌 가능한 코드 변경 사항을 조기에 감지해야합니다.

내가 볼 때 단점은

• main에서 병합은 수동으로 수행해야합니다 (또는 스크립팅).
• 더 많은 "관리"가 필요합니다

예, 자주 업데이트하는 것이 좋습니다. 어려운 병합 충돌을 피하기 위해 자주 업데이트하며 , 이는 다양한 변경 문제에 대한 소프트웨어 구성 관리 (SCM) 지식의 기본 사항입니다.

중앙 집중식이든 분산 형이든 상관 없습니다. DVCS의 경우 트렁크, 브랜치 또는 기타 리포지토리 인 경우 업스트림 소스에서 멀어 질수록 병합 충돌 가능성이 높아집니다. 예, 업데이트 할 때 팀의 불쾌한 놀라움이 올 수 있지만 불쾌한 연기를 연기하는 것은 훨씬 더 나쁩니다 (기다릴수록 더 많은 사람들이 왜 변경했는지 기억하지 못합니다).

작동하도록 업데이 트하기 위해서는 또한 코드 작업을하는 다른 프로그래머들이 의도 적으로 빌드를 중단하는 업스트림 코드를 커밋하거나 푸시해서는 안된다는 것을 의미합니다 . 이러한 상황이 불가피하게 발생할 경우, 팀원 및 기타 이해 관계자가 코드가 손상되는 것을 막기 위해 프로그래머가 지점 (또는 SCM 용어로 상류에서 벗어난)이되는 이유입니다.

기억하기 위해 사용할 수있는 진언은 "업데이트, 업데이트, 업데이트, 커밋"입니다. 커밋하기 전에 항상 변경 사항이 다른 사람과 작동하는지 확인하십시오. 이것은 또한 코드를 처음으로 체크 아웃하는 것도 확실하게하기위한 것입니다.

질문의 세 번째 글 머리 기호는 단순히 잘못되었습니다 .

• 완료하는 데 며칠이 걸리는 새로운 기능을 개발 중이며 빌드를 중단 할 수 있기 때문에 그 전에 커밋 할 수 없습니다.

얼마 동안 커밋 할 수없는 일을하고 있다는 것을 알고 있다면 그것은 브랜치를 사용하는 교과서의 예입니다.

보류중인 변경 사항이 많은 상황에 처하지 마십시오. 일정 기간 동안 프로젝트의 주요 지점에서 커밋 할 수 없다는 것을 알고 있다면 다른 지점에서 작업하십시오. 그리고 자주 커밋하십시오 .

질문에 설명 된 상황에 처한 경우 지금 지점으로 전환하고 변경 사항을 적용하고 해당 지점에서 계속 작업하십시오.

일반적으로 CVCS에서는 자주 업데이트하는 것이 좋습니다. 그러나 지점에서 작업하는 경우 "종종 업데이트 여부"라는 질문은 "병합 병합"이됩니다. 그리고 대답은 어쨌든 예입니다. 다른 지점에서 병합하기 전에 모든 보류중인 변경 사항 (지점에서)을 커밋하고 필요한 경우 병합을 안전하게 롤백하는 옵션으로 변경하십시오.

더 자주 커밋 해야한다고 생각합니다 . 며칠처럼 오랫동안 일할 계획이라면 트렁크에서 직접 작업하기보다는 코드를 분기하고 지점에서 작업해야합니다. 브랜치없이 작업을 시작하는 것이 편리하다는 것을 알고 있지만 업데이트 / 커밋이 코드를 손상 시킬지 여부를 확신 할 수 없기 때문에 실제로 유연하지 않습니다. 당신의 일을 끝냈습니다. "피처 브랜칭"은 항상 코드를 커밋하고 나중에 완료 할 때 다시 병합 할 수있는 방식으로 더 좋습니다.

분기 전략에서 업데이트는 트렁크에서 병합으로 대체됩니다. 내 경험상 5 일과 같은 코드가 크게 변경되지 않고 완료되면 한 번만 충돌을 해결하기 쉽기 때문에 트렁크에서 자주 병합 할 필요가 없습니다.

실제로 분산 버전 컨트롤을 로컬로 사용하는 것이 더 편리하다는 것을 알았습니다. 즉, git을 하위 버전 클라이언트로 사용합니다. 이것은 다음과 같은 장점이 있습니다.

• 로컬 변경 사항은 업데이트 전에 저장되므로 병합에 실수가 있으면 언제든지 돌아가서 다시 할 수 있습니다.
• 더 큰 변경을 수행하면 완료된 부품을 저장할 수 있습니다. 따라서 진행중인 나머지 변경 사항을보다 쉽게 ​​검토 할 수 있습니다.
• 더 큰 작업 중에 버그를 수정하면 해당 수정 사항 만 커밋하고 나머지는 일시적으로 커밋하고 수정 사항을 서브 버전에 "dcommit"하여 다른 작업을 로컬로 진행할 수 있습니다.

새 기능을 추가하는 경우 새 단일 소스 파일 (및 일치하는 외부 인터페이스 헤더 파일)을 작성할 수 있습니까?

"새로운 기능"이 널리 영향을 미칠까 걱정됩니다. 더 이상 객체 지향이 유행어가 아닐 수도 있지만 그 패러다임에는 장점이 있습니다.

그렇게하면 프레임 워크 (외부 인터페이스와 스텁 함수)를 만들고 나머지 개발을 끝내는 동안 최소한의 타사 효과가 있어야한다고 커밋 할 수 있습니까?

당신이 설명하는 상황에서는 더 적은 수의 큰 파일보다 더 작은 소스 파일을 갖는 것이 좋습니다.

중앙 집중식 버전 제어와 분산 제어의 차이점은 무엇입니까?

두 경우 모두 시작한 내용과 비교하여 내용이 이동 한 장소에서 체크인해야합니다. 중앙 저장소에서 작업장으로의 병합 빈도에는 차이가 없습니다 (프로젝트 지점은 작업장입니다).

나는 자주 병합하는 경향이 있습니다 (적어도 하루에 한 번, 다른 편리한 시간에 병합하거나 누군가 내가 작업중 인 것에 영향을 미치는 것을 체크인했을 때). 작은 변화를 흡수하는 것이 훨씬 쉬우 며 문제가있는 경우 1 주일 전에 체크인 한 것보다 방금 체크인 한 것에 대해 사람들이 더 도움이됩니다.

BTW, 나는 당신이 무엇을 "빌드 깨기"라고 몰라요. 비교적 작은 단위로 작업하는 경향이 있으므로 일부 기능이 중단 되더라도 컴파일 가능한 상태를 유지합니다. 그리고 테스트를 실행하여 병합이 작동해야 할 무언가를 손상시키지 않았 음을 알 수 있습니다. 다시 말하지만, 조기에 발견 될 때 문제점을 수정하는 것이 더 쉽습니다.

다른 사람이 빌드를 중단 할 때 "업데이트"상태에 따라 달라집니다. 한편으로는 가능한 한 작은 청크로 업데이트하려고합니다. 개인적으로, 나는 업데이트가있을 때마다 거의 업데이트합니다. 반면에 빌드가 중단되어 다른 사람이 수정하는 데 하루가 걸리더라도 그 동안 새로운 기능을 계속 사용할 수 있기를 원합니다.

업데이트가 완료되면 백업하기 어려운 버전 제어 시스템으로 작업했습니다. 따라서 체크인하기 직전에 업데이트하는 경향이 있습니다. 더 나은 버전 제어 시스템을 사용하면 하루에 여러 번 업데이트하지 않는 이유가 거의 없습니다.