분산 버전 제어

Distributed version control

소프트웨어 개발에서 분산 버전 제어(distributed version control이라고도 함)는 전체 이력을 포함한 완전한 코드베이스를 모든 개발자의 컴퓨터에 미러링하는 버전 제어의 한 형태다.[1]중앙 집중식 버전 제어에 비해 자동 관리 분기 및 병합이 가능하고, 대부분의 작업 속도(밀기 및 당기기 제외)가 빨라지며, 오프라인으로 작업할 수 있는 기능이 향상되고, 단일 위치 백업에 의존하지 않는다.[1][2][3]세계에서 가장 인기 있는 버전 제어 시스템인 Git은 분산형 버전 제어 시스템이다.[4]

2010년 소프트웨어 개발 저자 조엘 스폴스키는 분산형 버전 제어 시스템을 "지난 10년 동안 소프트웨어 개발 기술의 가장 큰 발전"이라고 설명했다.[2]

분산형 대 중앙 집중형

분산형 버전 제어 시스템(DVCS)은 중앙집중식 시스템의 클라이언트-서버 접근 방식과는 반대로 버전 제어에 대한 피어 투 피어 접근 방식을 사용한다.분산된 개정 제어는 피어에서 피어로 패치를 전송하여 리포지토리를 동기화함코드베이스의 단일 중앙 버전은 없다. 대신, 각 사용자는 작업 복사본과 전체 변경 내역을 가지고 있다.

중앙 집중식 시스템과 비교한 DVCS의 장점은 다음과 같다.

  • 네트워크에 연결되지 않은 경우 사용자가 생산적으로 작업할 수 있도록 허용.
  • DVCS는 중앙 서버와 통신할 필요가 없기 때문에 공통 작업(예: 커밋, 기록 보기 및 변경 되돌리기)이 더 빠르다.[5]DVCS에서는 다른 피어 간에 변경사항을 공유할 때만 통신이 필요하다.
  • 사용자가 발행하고 싶지 않은 초안에도 변경사항을 사용할 수 있도록 개인 작업을 허용한다.[citation needed]
  • 작업 복사본은 단일 장애 지점으로 하나의 물리적 시스템에 의존하지 않도록 원격 백업 기능을 효과적으로 수행하며,[5]
  • 개발지점이나 사령관/임계 모델을 사용하는 등 다양한 개발 모델을 사용할 수 있도록 한다.[citation needed]
  • 프로젝트의[citation needed] "릴리스 버전"에 대한 중앙 집중식 제어 허용
  • FOSS 소프트웨어 프로젝트에서는 리더십 갈등이나 설계상의 이견으로 인해 교착상태에 빠진 프로젝트에서 프로젝트 포크를 만드는 것이 훨씬 더 쉽다.

중앙 집중식 시스템과 비교한 DVCS의 단점:

  • 저장소의 초기 체크아웃은 모든 지점과 개정 내역이 기본적으로 로컬 컴퓨터에 복사되기 때문에 중앙화된 버전 제어 시스템의 체크아웃에 비해 느리다.
  • 대부분의 중앙 집중식 VCS에 속하며 그래픽 자산과 같은 입력 불가능한 이진 파일이나 너무 복잡한 단일 파일 이진 또는 XML 패키지(예: 사무실 문서, 전원)에 대해서는 여전히 중요한 역할을 하는 잠금 메커니즘의 결여BI 파일, SQL Server Data Tools BI 패키지 등).[citation needed]
  • 모든 사용자가 전체 코드베이스 기록의 전체 복사본을 보유하는 데 필요한 추가 스토리지.[6]
  • 모든 참가자가 지역적으로 취약한 복사본을 가지고 있기 때문에 코드 베이스의 노출 증가.[citation needed]

일부 원래 중앙 집중식 시스템은 현재 몇 가지 분산된 기능을 제공한다.예를 들어 서브버전은 네트워크 없이 많은 작업을 할 수 있다.[7]이제 Team Foundation Server 및 Visual Studio Team Services는 Git 호스팅을 통해 중앙 집중식 분산 버전 제어 저장소를 호스팅한다.

마찬가지로, 현재 일부 분산형 시스템은 마이크로소프트가 매우 큰 코드베이스를 사용하기 위해 개발한 Git용 가상 파일 시스템과 같이 체크아웃 시간과 스토리지 비용의 문제를 완화하는 기능을 제공하는데,[8] 이는 필요할 때만 로컬 스토리지에 파일을 다운로드하는 가상 파일 시스템을 노출시킨다.

작업 모델

분산형 모델은 일반적으로 리눅스 커널 프로젝트와 같이 부분적으로 독립적인 개발자가 있는 대규모 프로젝트에 더 적합하다. 개발자는 독립적으로 작업할 수 있고 병합(또는 거부)을 위해 변경사항을 제출할 수 있기 때문이다.분산 모델은 유연하게 사용자 정의 소스 코드 기여 워크플로우를 채택할 수 있다.통합자 워크플로우가 가장 널리 사용된다.중앙집중식 모델에서 개발자들은 다른 버전의 문제를 피하기 위해 그들의 작업을 직렬화해야 한다.

중앙 및 분기 저장소

모든 프로젝트에는 공식 리포지토리로 간주되는 중앙 리포지토리가 있으며, 프로젝트 유지 관리자에 의해 관리된다.개발자는 코드 베이스의 동일한 로컬 복사본을 만들기 위해 이 리포지토리를 복제한다.중앙 저장소의 소스 코드 변경은 로컬 저장소와 주기적으로 동기화된다.

개발자는 자신의 로컬 저장소에 새로운 분기를 만들고 그 분기에 소스 코드를 수정한다.개발이 완료되면 그 변화는 중앙 저장소로 통합될 필요가 있다.

요청 끌어오기

분산 버전 제어 시스템을 사용하는 소스 코드 저장소에 대한 기여는 일반적으로 병합 요청이라고도 하는 꺼내기 요청을 통해 이루어진다.[9]기여자는 프로젝트 유지관리자에게 소스 코드 변경을 요청하므로 "pull request"라는 이름을 사용하십시오.기부가 소스 베이스의 일부가 되어야 하는 경우 유지관리자는 당김 요청을 병합해야 한다.[10]

개발자는 새로운 변경사항을 유지관리자에게 알리기 위해 당김 요청을 작성한다. 각 당김 요청과 관련된 주석 쓰레드가 있다.이것은 코드 변경에 대한 집중적인 논의를 가능하게 한다.제출된 꺼내기 요청은 리포지토리 액세스 권한이 있는 모든 사용자가 볼 수 있다.당김 요청은 유지 관리자에 의해 수락 또는 거절될 수 있다.[11]

꺼내기 요청이 검토되고 승인되면 저장소로 병합된다.설정된 워크플로우에 따라 코드를 공식 릴리스에 포함하기 전에 테스트해야 할 수 있다.따라서 일부 프로젝트에는 검증되지 않은 끌어오기 요청을 병합하기 위한 특별 분기가 포함되어 있다.[10][12]다른 프로젝트에서는 Travis CI와 같은 지속적인 통합 도구를 사용하여 모든 꺼내기 요청에 대해 자동화된 테스트 세트를 실행하며, 심사자는 새로운 코드가 적절한 테스트 적용 범위를 가지고 있는지 점검한다.

역사

첫 번째 오픈 소스 DVCS 시스템은 Arch, Monotone, Darcs를 포함했다.그러나 오픈소스 DVCS는 Git와 Mercurial이 출시되기 전까지는 큰 인기를 끌지 못했다.

비트키퍼는 2002년부터 2005년까지 리눅스 커널 개발에 사용되었다.[13]현재 세계에서 가장 인기 있는 버전 제어 시스템인 Git의 개발은 Linus Torvalds와 다른 Linux 커널 개발자들이 이전에 이용했던 무료 라이선스를 BitKeeper가 삭제하도록 한 회사의 결정으로 촉발되었다.[4][13]

참고 항목

참조

  1. ^ a b Chacon, Scott; Straub, Ben (2014). "Getting Started – About Version Control". Pro Git (2nd ed.). Apress. Chapter 1.1. Retrieved 4 June 2019.
  2. ^ a b Spolsky, Joel (17 March 2010). "Distributed Version Control Is Here to Stay, Baby". Joel on Software. Retrieved 4 June 2019.
  3. ^ "Intro to Distributed Version Control (Illustrated)". www.betterexplained.com. Retrieved 7 January 2018.
  4. ^ a b "Version Control Systems Popularity in 2016". www.rhodecode.com. Retrieved 7 January 2018.
  5. ^ a b O'Sullivan, Bryan. "Distributed revision control with Mercurial". Retrieved July 13, 2007.
  6. ^ "What is version control: centralized vs. DVCS". www.atlassian.com. Retrieved 7 January 2018.
  7. ^ OSDir.com. "Subversion for CVS Users :: OSDir.com :: Open Source, Linux News & Software". OSDir.com. Archived from the original on 2016-08-23. Retrieved 2013-07-22.
  8. ^ Jonathan Allen (2017-02-08). "How Microsoft Solved Git's Problem with Large Repositories". Retrieved 2019-08-06.
  9. ^ Sijbrandij, Sytse (29 September 2014). "GitLab Flow". GitLab. Retrieved 4 August 2018.
  10. ^ a b Johnson, Mark (8 November 2013). "What is a pull request?". Oaawatch. Retrieved 27 March 2016.
  11. ^ "Using pull requests". GitHub. Retrieved 27 March 2016.
  12. ^ "Making a Pull Request". Atlassian. Retrieved 27 March 2016.
  13. ^ a b McAllister, Neil. "Linus Torvalds' BitKeeper blunder". InfoWorld. Retrieved 2017-03-19.

외부 링크