그 설명에 맞는 사람의 좋은 예는 프로젝트 관리자 일 수 있습니다.

나는 다른 날 상사에게 물었다. "이 Github가 무엇이며 왜 중요한가?" 그는 독점적 인 프로젝트를 수행하고 있기 때문에 개인 호스팅이 필요하며 평소보다 설명하기가 쉽지 않습니다. VCS는 협업을 사소하게 만들고 모든 데이터의 기록과 "백업"을 제공하며 코드 기반으로 원자 적 변화를 기록 할 수 있습니다 . 내 생각에, "그것은 그것이 얼마나 유익한 지 실제로 이해하기 위해 DRVS를 사용해야하는 것과 거의 같습니다."

나는 무제한의 개인 리포지토리를 제공하기 때문에 BitBucket을 가리키게되었습니다 (리포지토리가 무엇인지 설명해야했습니다).

VCS가 어떻게 엉덩이를 구했거나 인생을 더 편하게했는지에 대한 구체적인 예를 아는 사람이 있습니까?

버전 관리는 위대에 대한 (적어도) 세 네 가지 : 백업, 개발자 사이의 코드를 공유 버그 및 진행 추적을 고정 + 발견.

1. 백업 . 다른 것이 없다면 스테로이드 백업입니다. 전체 개발 히스토리가 있으며 각 커밋은 ID (개정 번호), 설명, 타임 스탬프, 사용자 정보가 포함 된 전체 코드의 스냅 샷입니다. 또한 수정본간에 파일을 비교하는 것이 간단합니다. 다른 것이 없다면 간단한 백업보다 빠르며 (파일 변경 만 전송 및 저장) 훨씬 유용한 메타 데이터가 포함되어 있습니다. 왜 이것을 재발 명합니까?

2. 개발자 사이에 코드를 공유 . 동일한 제품을 동시에 작업하는 개발자가 두 명 이상인 경우 코드 변경 사항을 안정적이고 일관되게 공유하고 병합 할 수있는 다른 방법이 없습니다. 우편으로 우편을 보내시겠습니까?

3. 버그 찾기 및 수정 . 고객이 특정 제품 버전에 대한 버그를보고하면 실제 소스 스냅 샷을 신속하게 확보하여이를 복제하고 수정할 수 있습니다. 소스가 고객과 다르면 버그를 재현하기가 어렵습니다. 분해 할 수 있도록 실행 파일을 보내도록 요청합니까? 또한 버그의 원인을 식별하는 데 문제가있는 경우 VCS를 사용하여 버그가 발생한 정확한 개정판을 정확하게 찾을 수 있습니다.

4. 진행 추적 . 스냅 샷에서 작업을 커밋하면 기능 관리자 및 오픈 버그 상태에 대한 진행 상황을 추적 할 수 있습니다. VC 시스템은 추적 시스템 및 지속적인 통합 시스템 과 쉽게 통합 됩니다. VCS가 없다면 취미 프로젝트 이외의 다른 것에 대한 수준의 품질을 유지하는 것은 거의 불가능합니다.

당신이 전혀 소프트웨어 개발해야한다고 동의하면 적 (심지어 취미 프로젝트를 위해 그것을 놓치지 않을 것)은 VCS 외부에서 수행되지, 당신은 노골적에서 복사 (약간 더 복잡한) DVCS의 기능 (다음 부분을 논의 할 수 Wikipedia ) :

• 각 사용자는 자체 저장소 의 로컬 사본 (및 사실상 백업 사본)을 갖습니다.
• 네트워크에 연결되어 있지 않아도 사용자가 생산적으로 작업 할 수 있습니다
• 네트워크가 없기 때문에 대부분의 작업을 훨씬 빠르게 수행
• 프로젝트 당국의 허가없이 프로젝트 참여 가능
• 개인 작업을 허용하므로 사용자는 게시하지 않으려는 초기 초안 에도 개정 제어 시스템을 사용할 수 있습니다
• 단일 물리적 시스템에 단일 장애 지점 으로 의존하지 않도록합니다.

" '실행 취소'버튼이 도움이 되었습니까? 그렇다면 버전 관리를 사용해야한다는 데 동의하십니까?"

버전 제어를 사용하기 시작했을 때 제가 관심을 보인 주요 기능은 실수를 취소하고 이전 버전으로 돌아가는 기능이었습니다. 실행 취소 버튼을 누구나 이해할 수 있습니다. 허가 된 버전 관리는 더 많은 것을 할 수 있습니다.

기본으로 시작하십시오.

첫째, VCS는 개발자를 자신과 서로로부터 보호합니다. 둘 이상의 개발자가 동일한 코드베이스에서 비교적 안전하게 작업 할 수 있도록하는 것 외에 다른 목적이 없다면 큰 가치가있을 것입니다. 며칠의 작업은 약간의 부주의 한 복사로 덮어 쓰기되었습니다).

두 번째로 감사 내역 (이력)을 제공합니다. 되돌아 가서 누가 언제 무엇을 변경했는지 확인할 수 있으며 나중에 더 이상 필요하지 않거나 적절하지 않기 때문에 삭제 한 코드를 다시 검색 할 수 있습니다. 모두.

셋째, 참조 점을 제공합니다. 결정적인 소스는 커밋 된 코드입니다 (실제 세계에서는 특히 DVCS에서는 조금 더 복잡하지만이 논의를 위해 충분히 가깝습니다). 리포지토리를 올바르게 백업 한 경우 회사 자산을 보호해야합니다.

관리자가 그 시간에 다른 관리자를 찾을 수있을만큼 충분한 가치를 볼 수없는 경우 VCS를 판매하기 위해서는이 세 가지가 "그것"이어야합니다.

VCS를 판매했다면 (결국 개발자 수가 0보다 큰 개발 팀에게만 사용) DVCS가 왜 SVN 또는 TFS를 초과하는지에 대한 질문과 작동 여부에 대한 추가 질문 사내에서 또는 Kiln 또는 Bitbucket 또는 Github와 같은 호스팅 서비스를 사용하는 경우 (비용을 지불하면 비공개) 다소 깊고 상황에 따라 다릅니다.

VCS

백업 의 개념을 설명하십시오 . 백업을 통해 특정 시점에 작업 한 내용을 볼 수 있습니다. VCS 프로그래머가 어떻게 전체 프로젝트를 강요 적으로 복사하기 전에, 일반적으로 각각의 좋고 안정적인 릴리스를 저장하기 위해 어떻게했는지 이야기하십시오. 그들 또는 다른 누군가 는 프로젝트의 전체 두 백업 대신 차이점을 살펴봄으로써 쉽게 엉망이되어 문제를 해결했습니다 .

요약 : VCS를 사용하면 작업의 백업 을 저장하고 백업 간의 차이점 만 볼 수 있습니다.

DVCS

분산 버전 제어의 경우 일반적인 버전 제어 에 서버와 인터넷 연결 이 필요한 방법과 속도가 느리고 모두가 하나의 백업으로 작업했기 때문에 모든 사람이 피곤하다고 설명합니다. 분산 버전 제어 기능을 사용하면 모든 사람이 인터넷에 연결하지 않고도 자신의 컴퓨터에서 자체 백업 작업을 수행 할 수 있으며 작업하는 동안 백업을 엉망으로 만들지 않고 나중에 작업을 공유 할 때 걱정할 수 있기 때문에 모든 사람이 행복 합니다.

또 하나의 좋은 방법은 백업이 하나만있는 중앙 집중식 VCS와 달리 백업이있는 머신에서 화재가 발생하더라도 다른 전체 백업이 계속 진행될 수 있다는 것입니다 (각 개발자마다 하나 이상).

요약 : DVCS 를 사용하면 모든 사람이 서로 귀찮게 단일 서버에서 충돌 하지 않고도 자신의 백업 작업을 수행 할 수 있으며 작업이 끝나면 다른 변경 사항에 대해 걱정할 수 있습니다. 또한 기본 리포지토리 시스템에서 화재가 발생하면 아무 일도 일어나지 않습니다 .

나는 주로 엔지니어와 함께 일합니다 (개발자 자체는 아니지만 코드를 작성합니다)

버전 관리에 대해 설명 할 때 주요 요점은 코드 / 문서 / 무엇이든 실행 취소 및 관리하고 다른 개발자 / 작성자 / 등과의 협업을 단순화 할 수 있다는 것입니다.

그것은 좋은 판매 포인트입니다. 그리고 모든 작업에 VCS를 사용하는 주된 이유였습니다. 역사, 쉽게 백업 할 수있는 리포지토리를 갖는 것 ...

그들 대부분은 아이디어를 좋아하고 프로젝트에 적용 할 때 특히 유용합니다 (특히 다른 엔지니어와 협력하는 경우).

누군가를 설득하려고 할 때, 항상 그들의 관점에서 그것을 시도해야합니다.

프로젝트 관리자는 시간과 예산에 맞춰 프로젝트를 완료하는 간단한 목표를 가지고 있습니다.

현재 버전 관리를 사용하지 않는 경우 개발 팀에서 버전 관리로 해결되는 문제를 직접 해결하고 있습니다. 이러한 모든 문제는 다른 답변으로 잘 열거되어 있으므로 여기서 다루지 않겠습니다.

해야 할 일은 XGIT가 자동으로 또는 0.1 * X개발자 시간 수와 같이 해결할 수있는 문제를 수동으로 해결하기 위해 팀이 매주 시간을 보내고 있다는 것을 프로젝트 관리자에게 설명하는 것 입니다.

GIT가 여러분의 삶을 편하게하거나 동료 개발자의 삶을 편하게하는 이유를 사용하여 접근하지 마십시오. GIT가 소프트웨어를보다 빠르고 저렴하게 제공 할 것이라는 관점에서 접근하십시오.

코드베이스에 대한 실행 취소 버튼으로 @ Buttons840의 설명이 마음에 듭니다. 또한 실망스럽지 않은 Word 버전이나 InDesign의 "변경 내용 추적"기능과 비교하는 데 도움이 될 수 있습니다. 내 경험상, 한 사람이 다음 몇 시간 동안 파일 X, Y 및 Z를 만지지 말라고 다른 사람에게 이야기 할 필요성을 분명히 줄입니다.

또한 세분화 된 버전 정보는 버그 수정 / 작업에 매우 유용합니다. 내가 생성하는 거의 모든 데이터 파일에서 SVID 버전 번호 ($ Id 속성을 통해)를 숨 깁니다. 이런 식으로 버그가 발견되면 잠재적 인 문제가있는 파일을 식별하여 파일을 재생성하거나 다른 코드로 버그를 보상하는 것이 쉽지 않습니다.

버전 관리를 사용하지 않는 경우 프로덕션 환경을 재 구축하는 방법을 어떻게 알 수 있습니까?

1 다른 사람들 (테스터, 개발자)은 다른 장소에서 동일한 정보를 찾습니다

동기화되지 않은 중복 데이터로 연결됩니다.
버전 제어는 중복 데이터를 제거하는 가장 쉬운 방법입니다.

2 버전 제어를 사용하는 경우 프로덕션 환경이 버전 제어에있는 것과 일치하는지 쉽게 확인할 수 있습니다.

이를 통해 문제가 빌드가 잘못되어 (prod가 버전 관리와 일치하지 않음) 또는 디자인 또는 코딩 버그 (prod가 버전 관리와 일치 함)인지 여부를 쉽게 감지 할 수 있습니다.

버전 관리를 통해 각 테스트 환경에 릴리스 번호를 쉽게 할당 할 수 있으며 프로덕션 환경에서 테스트 또는 개발보다 릴리스 번호가 낮고 개발시 릴리스 번호가 낮을 것으로 예상 할 수 있습니다. 그렇지 않은 경우 코드의 일부가 제대로 테스트되지 않은 것입니다.

또한 소프트웨어를 릴리스하는 경우 VCS의 다음 기능이 필수적입니다. 고객이 버그를 발견했다고 가정하십시오. 현재 소프트웨어 개발은 ​​고객의 버전과는 매우 다른 상태 일 것입니다. 현재 버그가 수정되었을 수도 있고 아닐 수도 있지만 현재 소프트웨어는 고객에게 배송 할 수있는 상태가 아닙니다.

VCS를 사용하면 고객에게 제공된 버전으로 돌아가서 요청한 버그를 수정하고 빌드 한 후 수정 된 버전을 제공 할 수 있습니다. 미완성 / 불안정한 기능 또는 새로운 미완성 개발로 인한 추가 버그가있는 버전을 제공 할 필요없이 현재 개발을 방해하지 않고이 모든 것을 수행 할 수 있습니다.

또한 VCS를 사용하면 버그가 여전히 존재하는 경우이 수정 프로그램을 새로운 개발 지점으로 쉽게 다시 포팅 할 수 있습니다.

강력한 규율을 통해 매우 작은 팀을 위해 VCS없이이를 관리 할 수 ​​있지만 팀을 사용하면 시간과 비용을 절약 할 수 있습니다. 고객 유지에 도움이 될 것입니다.

회사에 두 명 이상의 직원이있는 경우 여러 사람이 편집 할 수있는 단어 문서 나 Excel 문서가있을 수 있습니다. 때로는 그러한 사람들이 출장을 위해 현지 사본을 만들거나 문서가 변경 될 때마다 이메일로 문서를 보냅니다.

이러한 파일이 있으면 과거에 일부 사람들의 수정 사항이 손실되었거나 향후에 손실 될 수 있습니다. 또는 사람들은 변경 사항을 잃어 버렸다고 생각하지만이를 입증 할 수는 없습니다. 또는 누가 언제, 왜 어떤 변화를 겪었는지 확인하고 싶습니다. 이것이 바로 VCS가 해결하는 문제입니다.

오픈 소스 소프트웨어 / 라이브러리를 선택할 때 DVCS 리포지토리를 갖는 것이 선택 기준에서 확실히 유리합니다.

1) 전체 저장소를 복제 할 수 있으므로 프로젝트에 대해 걱정할 필요가 없으며 웹 사이트가 죽었습니다.

2) 사람들은 풀 요청을 통해 버그 수정을 기꺼이 제출하여 긴급한 문제에 대한 버그 수정이 더 빠릅니다.