모두가 왜 중앙 집중식으로 Git을 사용합니까?

지난 두 회사에서 버전 관리를 위해 Git을 사용했습니다. 회사의 약 90 %가 다른 버전 제어 시스템보다 Git을 사용한다고 들었습니다.

Git의 가장 큰 판매 포인트 중 하나는 분산되어 있다는 것입니다. 즉, 모든 리포지토리가 동일합니다. 중앙 저장소 / 진리가 없습니다. 이것은 Linus Torvalds가 챔피언으로 삼은 기능 이었습니다.

그러나 모든 회사는 SVN 또는 CVS를 사용하는 것처럼 중앙 집중 방식으로 Git을 사용하는 것으로 보입니다. 사람들이 끌어 당기는 서버 (일반적으로 GitHub)에는 항상 중앙 저장소가 있습니다. 나는 (확실히 제한된 경험으로) Git을 의도 한 탈 중앙화 방식으로 사용하는 사람들을 보거나 들어 본 적이 없다.

내 질문은 :

1. 실제로 사람들이 실제로 Git에 분산 워크 플로를 사용하지 않는 이유는 무엇입니까?
2. 분산 방식으로 작업 할 수있는 기능이 최신 버전 관리에 중요합니까, 아니면 좋은 소리입니까?

편집하다

나는 원래의 질문에서 올바른 어조를 얻지 못했다는 것을 깨달았다. 분산 버전 제어 시스템 (DVCS)이 그토록 우월 했을 때 누군가 중앙 집중식으로 작업하는 이유를 묻는 것처럼 들렸습니다 . 실제로, 내가 말하고자하는 것은 DVCS에 어떤 이점도 전혀 보지 못했다는 것 입니다. 그러나 나는 종종 사람들이 그 우월성을 설교하는 것을 듣는 반면, 실제 세계는 나의 견해에 동의하는 것 같습니다.

아,하지만 사실은 당신이 하는 분산 방식으로 자식을 사용!

git의 전임자를 mindshare, svn에서 비교해 봅시다. Subversion은 하나의 "레포", 하나의 진실 소스를 가졌습니다. 커밋을 할 때는 다른 모든 개발자도 커밋 한 단일 중앙 리포지토리를 사용했습니다.

이런 종류의 작업이 이루어졌지만 수많은 문제가 발생했으며 가장 큰 문제는 두려운 병합 충돌 입니다. 이것들은 해결하기 위해 성가신 것에서부터 악몽에 이르기까지 어디에서나 밝혀졌습니다. 그리고 한 가지 진실의 근원으로, 그들은 해결 될 때까지 모든 사람의 일을 끔찍한 멈춤으로 가져 오는 불쾌한 습관을 가졌습니다. 병합 충돌은 분명히 git과 함께 존재하지만 작동 중지 이벤트가 아니며 훨씬 쉽고 빠르게 해결할 수 있습니다. 일반적으로 모든 사람이 아니라 충돌하는 변경과 관련된 개발자에게만 영향을줍니다.

그런 다음 단일 실패 지점 전체와 수행자 문제가 발생합니다. 중앙 svn 저장소가 어떻게 든 죽으면 백업에서 복원 할 수있을 때까지 모두 망쳐 놓았으며 백업이 없으면 모두 이중으로 망쳤습니다. 그러나 "중앙"git repo가 ​​죽으면 백업 또는 CI 서버, 개발자 워크 스테이션 등에있는 다른 repo 사본 중 하나에서 복원 할 수 있습니다. 각 개발자는 일류의 레포 사본을 가지고 있습니다.

반면, git repo 는 그 자체로 일류 repo이므로 커밋하면 커밋이 로컬 리포지토리로 이동합니다. 다른 사람 또는 중앙 진실의 근원과 공유하려면 원격으로 푸시하여 명시 적으로 수행해야합니다. 그런 다음 다른 개발자가 편리한 경우 변경 사항을 풀다운하여 svn을 지속적으로 확인하여 누군가가 실수를 저지른 작업을 수행했는지 확인하지 않아도됩니다.

다른 개발자에게 직접 푸시하는 대신 다른 원격 저장소를 통해 변경 사항을 간접적으로 푸시 한다는 사실은 중요하지 않습니다. 우리의 관점에서 중요한 부분은 귀하의 리포지토리 사본이 그 자체로 리포지토리라는 것입니다. svn에서 시스템의 설계에 의해 진리의 중심이 강화됩니다. git에서 시스템은이 개념조차 가지고 있지 않습니다. 진실의 근원이 있다면, 그것은 외부 적으로 결정됩니다.

빌드 서버 ( CI 를 사용하고 있습니까?)가 빌드를 만들면 어디에서 가져 옵니까? 물론, 당신이 주장 할 수있는 통합 빌드에는 "하나의 진정한 저장소"가 필요하지 않지만 반드시 배포 빌드 (즉, 고객에게 제공하는 것)가 필요합니다.

다시 말하면 조각화. 한 레포를 "the"레포로 지정하고 풀 요청을 심사하는 보호자를 지정하는 경우 "소프트웨어 빌드 제공"또는 "팀에 익숙하지 않습니다. 코드는 어디에 있습니까?"라는 요청을 쉽게 충족 할 수 있습니다.

DVCS의 강점은 P2P 측면이 아니라 계층 적이라는 사실입니다 . 작업 공간을 수정 한 다음 로컬로 커밋합니다. 기능이 완성되면 커밋을 병합하여 리모컨으로 푸시합니다. 그런 다음 풀 요청을 작성하고 프로젝트 관리자가 코드를 One True 저장소에 병합하기 전에 누구나 내 임시 코드를보고 피드백을 제공 할 수 있습니다.

전통적인 CVCS를 사용하면 커밋하거나하지 않습니다. 일부 워크 플로 (다른 프로젝트에 두 VCS 유형을 모두 사용)에는 적합하지만 공개 또는 OSS 프로젝트의 경우 평평합니다. 중요한 점은 DVCS에 여러 단계가있어 더 많은 작업을 수행하지만 체크인 프로세스에 대한 가시성을 향상시키는 내장 프로세스를 통해 낯선 사람의 코드를 통합하는 더 좋은 방법을 제공한다는 것입니다. 중앙 집중식으로 코드를 사용하면 여전히 더 나은 코드 공유 메커니즘을 제공하면서 프로젝트의 현재 상태에 대한 황금 표준을 갖추십시오.

난 당신이 "모든 사람"을 정의하는 방법을 모른다,하지만 내 팀과 "서버에서 중앙의 repo"이 또한 우리가 중앙의 repo를 통해 이동하지 않고 다른 동료의 repos에서 끌어 때때로을. 이 작업을 수행 할 때 우리는 여전히 서버를 통해 이동합니다. 왜냐하면 우리는 장소에 대한 패치를 이메일로 보내지 않고 중앙 저장소를 통해서는 안됩니다. 이는 일반적으로 그룹이 특정 기능에 대해 협업하고 있고 서로 최신 상태를 유지하려고하지만 모든 사람에게 기능을 게시하는 데 관심이없는 경우에 발생합니다. 당연히 우리가 비밀 사일로 작업자가 아니기 때문에 이러한 상황은 오래 가지 않지만 DVCS는 가장 편리한 것을 수행 할 수있는 유연성을 제공합니다. 취향에 따라 기능 분기를 게시하거나 게시하지 않을 수 있습니다.

그러나 시간의 90 % 이상은 물론 중앙 저장소를 거치게됩니다. 특정 변경 사항이나 특정 동료의 작업에 신경 쓰지 않을 때 더 편리하고 확장 성이 좋으며 각 N에서 개별적으로 변경 사항을 가져 오는 대신 "중앙 저장소에서 심사를 거친 모든 동료의 변경 사항"을 가져 오는 것이 더 편리합니다. 동료. DVCS는 "주 리포지토리 풀 (pull from main repo)"이 가장 일반적인 워크 플로우가되는 것을 막으려 고하지 않고 유일하게 사용 가능한 워크 플로우가되는 것을 막으려 고합니다.

"배포 됨"은 git소프트웨어에 관한 한 모든 저장소가 기술적으로 동등 하지만 개발자와 워크 플로에 관한 한 모두 동일한 의미를 갖는 것은 아닙니다. 클라이언트 또는 프로덕션 서버에 배포 할 때 랩톱의 한 개발자 만 사용하는 리포지토리와 다른 의미를 갖는 리포지토리를 사용합니다.

"진정으로 분산"는 "특별한 REPOS가없는"을 의미한다면 나는 그 리누스는 사실의 점에서 그는 주어진, 챔피언에게 어떤 의미인지 생각하지 않는 특수의 repos 유지 되어 보다 사물의 웅대 한 계획에 더 중요 어제 Linux의 임의 복제본으로, 작은 패치를 개발 한 다음 패치를 수락 한 후에 만 ​​삭제하려고 계획합니다. git내 리포지토리에 대한 특권 은 없지만 Linus 가 특권을 부여합니다. 그의 "현재 리눅스 상태"는 그렇지 않다. 자연스럽게 변화 하는 경향이 있습니다리누스를 통과합니다. 중앙 집중식 VCS에 비해 DVCS의 강점은 사실상의 센터가 없어야한다는 것이 아니라, 누군가가 무엇이든 병합 할 수 있기 때문에 변경이 어떤 센터를 거치지 않아도된다는 것입니다.

DVCS 시스템은 또한 강제 가 분산되기 때문에 로컬 아무것도하기 위해 당신이 반드시 완전한 역사 (즉, REPO)가 있어야한다는 사실을 기반으로 특정 편리한 기능을 제공하는. 그러나 그것에 대해 생각하면 읽기 전용 작업의 전체 기록을 최신 상태로 유지하는 로컬 캐시로 중앙 집중식 VCS를 구성 할 수없는 근본적인 이유는 없습니다 (Perforce에는이 모드에 대한 옵션이 있다고 생각합니다. 그러나 나는 Perforce를 사용한 적이 없다.) 또는 원칙적으로는 구성 할 수 있습니다 git로.git/네트워크에 연결되어 있지 않은 경우 작동하지 않는 SVN의 "기능"을 에뮬레이트하기 위해 원격 마운트 파일 시스템의 디렉토리. 사실상 DVCS는 중앙 집중식 VCS에서 벗어날 수있는 것보다 배관을 더욱 강력하게 만듭니다. 이것은 (매우 반가운) 부작용이며 DVCS 설계에 동기를 부여하는 데 도움이되었지만 기술 수준 에서의 책임 배분은 모든 인간 책임 을 완전히 분산시키는 것과 같지 않습니다 .

DVCS의 특성에 대한 흥미로운 점은 다른 사람들이 분산 방식으로 그것을 사용하고 있다면 그들이 당신과 직접 상호 작용하지 않으면 그것을 알지 못할 것입니다. 당신은 확실히 말할 수있는 유일한 방법은 것입니다 당신 과 당신의 직접적인 동료가 이런 식으로 이눔 사용하지 마십시오. 회사 전체의 정책이 필요하지 않습니다. 그래서 당신에게 물어볼 것입니다. 왜 분산 형으로 git 을 사용 하지 않습니까?

편집을 해결하려면 차이를 인식하기 위해 실제 중앙 집중식 버전 컨트롤을 사용한 경험이 필요합니다. VCS를 중앙 집중화 할 때 수행 할 수 없었던 작업이 팀에서 실제로 수행하는 모든 작업은 다음과 같습니다.

• 각 마이크로 서비스의 "중앙"저장소에 대한 커밋 액세스 권한이있는 핵심 개발자 목록이 매우 적습니다. 다른 사람은 포크를 사용하여 풀 요청을 통해 제출할 수 있습니다.
• 커밋 수 많은 시간 당 보통 여러 번 한 번 또는 두 번 하루에 비해 더 자주.
• 어떤 이유로 든 동료와 일시적으로 협력 할 수있는 지점을 만들어 하루에 여러 번 밀고 나서 더 큰 그룹과 공유 할 준비가되면 스쿼시 할 수 있습니다. 전통적인 CVCS에서 이와 같은 임시 브랜치를 생성하는 것이 얼마나 어려운지 아십니까?

말을한다고해서 오래된 소리를 낼 위험이 있다면 실제로 얼마나 쉬운 지 알 수 없습니다.

당신이 질문하는 것은 항상 이해할 수있는 항상 연결된 사고 방식 에서 비롯된 것 같습니다 . 즉 , 중앙 '진실'ci 서버는 항상 사용 가능합니다. 이것은 대부분의 환경에서 사실이지만 적어도 이것과는 거리가 먼 곳에서 일했습니다.

우리 팀이 몇 년 전에 일한 군사 시뮬레이션 프로젝트. 모든 코드 (우리는을 얘기> US $ 1B 코드베이스) 로 한 기계에있을 (당신이하지 않으면 법 / 국제 협정에 의해, 어두운 정장 남성 올) 물리적으로 분리 어떤 인터넷 연결 . 이것은 우리 각자의 일반적인 상황에 각각 2 개의 PC가 있는데, 하나는 코드를 작성 / 실행 / 테스트하기위한 것이고, 다른 하나는 Google에 이메일을 보내기위한 것입니다. 그리고 이러한 머신 팀 내부에는 로컬 네트워크 가 있었으며 인터넷에는 전혀 연결되지 않았습니다.

"중심의 진리의 원천"은 모든 콘크리트 블록 지하 창문이없는 방 (야마다 ​​야다 강화 건물)에있는 기지에있는 기계였습니다. 그 기계 는 또한 인터넷에 연결되지 않았습니다.

주기적으로 git repo (모든 코드 변경 사항 포함)가있는 드라이브를 수백 킬로미터 떨어진 군대 기지로 (물리적으로) 운송하는 것이 누군가의 일입니다. 그래서 상상할 수 있습니다.

또한,에 매우 큰 시스템 당신은 어디에서 많은 팀을. 그들은 일반적으로 그들 자신의 "중앙"레포지토리를 가질 것이고, 그 후 실제 (신 계층) "중앙"중앙 레포로 되돌아 간다. 나는 동일한 하드 드라이브 git repo 대시를 코드로 사용하는 다른 계약자 1 명 이상을 알고 있습니다.

또한 리눅스 커널 규모로 무언가를 고려한다면 개발자는 Linus에게 풀 요청을 보내는 것이 아닙니다. 본질적으로 레포의 계층 구조입니다. 각 레포는 누군가 / 일부 팀에게 "중앙"입니다.

git의 연결이 끊어진 특성은 연결된 모델 소스 제어 도구 ( 예 : SVN)를 사용할 수 없거나 쉽게 사용할 수없는 환경에서 사용할 수 있음을 의미합니다 .

궁극적으로, 당신은 제품을 만들고 있습니다. 이 제품은 특정 시점의 코드를 나타냅니다. 주어진 코드는 어딘가에 통합되어야합니다 . 자연스러운 지점은 제품이 구축되는 ci 서버 또는 중앙 서버이며이 중앙 지점은 git 저장소라는 것이 합리적입니다.

DVCS의 분산 측면은 오픈 소스 개발에서 항상 포크 형식으로 나타납니다. 예를 들어, 내가 기여한 프로젝트 중 일부는 원래 작성자에 의해 포기되었으며 이제 관리자가 때때로 특정 기능을 서로 가져 오는 많은 포크가 있습니다. 일반적으로 OSS 프로젝트는 임의의 사람들에게 근거리 저장소에 대한 액세스 권한을 부여하는 대신 풀 요청을 통해 외부 기여금을받습니다.

구체적인 공식 릴리스를 사용하여 구체적인 제품을 제작할 때 매우 일반적인 사용 사례는 아니지만 F / OSS 세계에서는 예외가 아닙니다.

왜 모든 사람들이 git을 중앙 집중식으로 사용합니까?

우리는 한번도 만난 적이 없습니다. 당신은 어떻게 모든 사람을 말합니까? ;)

둘째, Git에는 있지만 CVS 또는 SVN에는없는 다른 기능이 더 있습니다. 아마 당신이이 있어야한다는 가정하에있어 단지 기능 에 대한 모든 .

많은 사람들이 CVS 또는 SVN처럼 중앙 집중식으로 사용할 수 있습니다. 그러나 기본적으로 분배 된 VCS와 함께 제공되는 다른 기능을 잊지 마십시오. 모든 사본이 어느 정도 "완료"(모든 지점 및 전체 히스토리 사용 가능)되며 모든 지점은 서버에 연결하지 않고 체크 아웃 할 수 있습니다.

내 생각에 이것은 잊어서는 안되는 또 다른 기능입니다.

즉시 사용 가능한 CVS 및 SVN으로는이 작업을 수행 할 수 없지만 Git은 문제없이 중앙 집중식으로 사용할 수 있습니다.

따라서 변경 사항을 커밋하고 스쿼시 작업 커밋을 함께 커밋 한 다음 내 작업을 가져 와서 기본 개발 지점으로 리베이스 할 수 있습니다.

Git과 함께 제공되는 다른 기능들 :

• 암호화 서명 커밋
• rebasing (재주문 및 스쿼시 커밋; 메시지뿐만 아니라 커밋 편집)
• 체리 따기
• 역사를 이등분하다
• 지역 지점 및 보관 변경 (위키 백과에서는 "선반"이라고 함)

또한 Wikipedia의 다음 세 가지 표를 참조하십시오 -버전 제어 소프트웨어 비교 :

• 풍모

• 기본 명령

• 고급 명령

다시 말하지만, 탈 중앙화 된 방식은 사람들이 그것을 사용하게 만드는 기능 만 이 아닙니다 .

1. 실제로 사람들이 실제로 Git에 분산 워크 플로를 사용하지 않는 이유는 무엇입니까?

Bitbucked, GitHub 등에서 더 큰 프로젝트에 기여하거나 호스팅하는 사람이라면 누구나 그렇게 할 것입니다. 유지 관리자는 컨트 리뷰 터 복제 본인 "메인"리포지토리를 유지하고 풀 요청을 커밋 한 다음 보냅니다.

소규모 프로젝트 나 팀이있는 회사에서도 분산 워크 플로는 모듈을 아웃소싱하고 외부에서 변경 사항을 검토하지 않고 신성한 개발 지점을 수정하기를 원하지 않는 경우 옵션입니다.

2. 최신 버전 관리에 있어서도 분산 방식으로 작동하는 능력이 중요합니까?

항상 그렇듯이 요구 사항에 따라 다릅니다.

포인트가 적용되는 경우 분산 VCS를 사용하십시오.

• 히스토리를 오프라인으로 커밋하거나 탐색하려는 경우 (예 : 휴가 기간 동안 산장의 하위 모듈 완료)
• 중앙 저장소를 제공하지만 변경 내용을 검토하기 위해 "진정한"저장소를 별도로 유지하려는 경우 (예 : 대규모 프로젝트 또는 분산 된 팀)
• 중앙 리포지토리에 직접 액세스하지 못하게하고 (두 번째 리포지토리와 유사) 때때로 전체 기록과 분기를 제공 (복사본)하려고합니다.
• 원격으로 저장하거나 전용 리포지토리를 설정하지 않고도 무언가를 버전 관리하고 싶습니다 (특히 Git을 사용하면 git init .무언가를 버전 화 할 준비가되어 있어야합니다)

몇 개 더 있지만 4 개이면 충분합니다.

... 아니면 그냥 좋은 소리입니까?

물론 초보자에게는 좋습니다.

유연성은 저주이며 축복입니다. 힘내 매우 유연로, 그것은 거의 항상 지금까지 일반적인 상황에 너무 유연한. 특히, 대부분의 Git 프로젝트는 Linux가 아닙니다.

결과적으로 현명한 선택은 Git을 구현할 때 이론상의 유연성 중 일부를 제거하는 것입니다. 이론적으로 리포지토리는 모든 그래프를 형성 할 수 있으며 실제로 일반적인 선택은 트리입니다. 그래프 이론을 사용하면 분명한 이점을 볼 수 있습니다. 리포지토리 트리에서 두 리포지토리는 정확히 하나의 조상을 공유합니다. 무작위 그래프에는 조상의 아이디어조차 존재하지 않습니다!

그러나 git 클라이언트는 기본적으로 "단일 조상"모델로 기본 설정되어 있습니다. 그리고 노드에 단일 조상이있는 그래프 (루트 노드 제외)는 정확히 트리입니다. 따라서 git 클라이언트 자체는 기본적으로 트리 모델이므로 중앙 집중식 리포지토리입니다.

비즈니스 로직은 중앙 서버에 보상합니다. 거의 모든 실제 비즈니스 시나리오에서 중앙 서버는 워크 플로의 기본 기능입니다.

DVCS를 수행 할 수 있다고해서 기본 작업 흐름이 DVCS 여야한다는 의미는 아닙니다. 직장에서 git을 사용할 때 분산 비트가 물건을 계속 움직이게하는 이상한 이상한 경우를 제외하고는 중앙 집중식으로 사용합니다.

사물의 분산 측면은 복잡합니다. 일반적으로 일을 부드럽고 쉽게 유지하려고합니다. 그러나 git을 사용하면 분산 된쪽에 액세스하여 길에서 발생할 수있는 끔찍한 상황을 처리 할 수 ​​있습니다.

동료가 내 컴퓨터의 git repo에서 가져 오는 것은 루트 작업에서 백그라운드 작업으로 git 데몬을 실행해야한다는 것을 의미합니다. 나는 내 컴퓨터 나 회사에서 제공 한 랩톱에서 실행되는 데몬에 대해 매우 불안합니다. 가장 쉬운 해결책은 "아니오"입니다! 동료가 내 컴퓨터의 git repo에서 가져 오려면 인터넷 주소를 고정해야합니다. 나는 여행을하고 집에서 일을하고 때로는 사무실에서 일을합니다.

반면, 회사 사이트에 VPN을 사용하고 지점을 중앙 리포지토리로 푸시하는 데 1 분도 걸리지 않습니다. 사무실에 있으면 VPN을 할 필요조차 없습니다. 동료가 해당 지점에서 쉽게 끌어 올 수 있습니다.

세 번째로, 내 로컬 git repo는 모든 기능을 갖춘 저장소입니다. 새로운 작업을 수행하고 실험 작업을위한 새로운 브랜치를 생성하며, 아무데도 중간에 30,000 피트를 날고있는 비행기에서 일하고있을 때라도 엉망인 작업을 되돌릴 수 있습니다. 중앙 집중식 버전 제어 시스템으로이를 시도하십시오.

복잡성:

중앙 저장소를 사용하면 일반적인 작업 흐름은 다음과 같습니다.

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

O (1)의 개발자 수에 대한 복잡성.

대신 각 개발자가 자신의 마스터 브랜치를 가지면 개발자 0의 경우 :

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

피어 투 피어 접근 방식은 O (N)입니다.

일관성:

이제 Alice의 마스터 브랜치와 Bob의 마스터 브랜치간에 병합 충돌이 있는지 고려하십시오. 각 N 개발자는 갈등을 다르게 해결할 수 있습니다. 결과 : 혼돈. 최종 일관성을 달성 할 수있는 방법이 있지만 그럴 때까지 모든 종류의 개발자 시간을 낭비 할 수 있습니다.

단순한:

회사는 중앙 집중식 워크 플로가있는 중앙 집중식 조직입니다.

모든 프로그래머에게는 보스가 있고 CTO까지 보스가 있습니다. CTO는 기술적 진실의 궁극적 인 원천입니다. 툴 회사가 무엇을 사용하든,이 명령 체인을 반영해야합니다. 회사는 군대와 같습니다-당신은 개인이 장군을 외면 할 수 없습니다.

GIT는 회사에 유용한 기능 (예 : 코드 검토를위한 풀 요청)을 제공하며 GIT로 전환하는 기능 만 제공합니다. 분산 부분은 단순히 필요하지 않은 기능이므로 무시합니다.

귀하의 질문에 대답하기 위해 : 분산 부분은 실제로 분산 소스 (예 : 오픈 소스)에서 우수합니다. 말하는 사람에 따라 결과가 다릅니다. Linus Torvalds는 정확히 큐비클 쥐가 아니기 때문에 github 중심 회사보다 GIT의 다른 기능이 중요합니다.

급여 처리가 중앙 집중식이기 때문에 지불을 받으려면 중앙 사람을 행복하게 유지해야 할 수도 있습니다.

제품을 하나 만들고 있기 때문에 고객을위한 소프트웨어의 마스터 사본이 필요합니다.

아마도 많은 다른 기계에 연결하지 않고 프로그래머가 한 곳으로 가서 모든 사람의 변경 사항을 얻는 것이 훨씬 쉽기 때문일 수 있습니다.

버그 데이터베이스가 중앙 집중화 되어 코드와 동기화되어 있어야 하기 때문일 수 있습니다 .

문제가 생길 때까지 집중화되는 것은 훌륭합니다… ..

분산 시스템 인 Git은 최신 리포지토리에서 저렴한 비용으로 새로운 센터를 만들 수 있습니다 (리포지토리를 네트워크에 노출). 또한 Git을 사용하면 개발자 머신의 리포지토리에서 오래된 백업을 업데이트 할 수 있으므로 센터를보다 쉽게 ​​복구 할 수 있습니다.

네트워크가 다운되었을 때 리포지토리의 로컬 복사본에서 병합 등을 수행 할 수 있다는 것은 훌륭하지만 분산 시스템은 필요하지 않습니다. 모든 데이터의 로컬 사본을 보관하는 시스템 만 있으면됩니다. 비행 등으로 코드를 체크인하는 것과 마찬가지로

하루가 끝나면 배포 비용과 혜택이 거의 없습니다. 배포 비용의 대부분은 지점 등을 추적하려는 경우 필요한 영역에 있습니다. 대부분의 회사에서 사용할 시스템을 설계하려는 경우 소스 코드를 중앙 집중식으로 제어하여 배포하지 않도록 설계합니다 분명히 "사용 사례"입니다.