전문 응용 프로그램 개발자는 GIT 및 Subversion과 같은 버전 제어 시스템을 어떻게 사용합니까?

나는 초보자 개발자이며 처음부터 GIT 및 Subversion과 같은 전문가 용 도구 (이 도구에 대해 잘 이해하지 못함)가 프로젝트의 요구를 충족시키는 방법을 궁금해하고 있습니다. 그들이 그것을 사용한다면, 어떻게 그런 것을 설정합니까?

내 응용 프로그램이 너무 크지 않고 팀에서 아직 일하고 있지 않습니다. 큰 도움이 되겠습니까?

이 사이트에는 도구 사용 방법에 대한 질문이 있지만 초보자 지원이 필요합니다.

소스 컨트롤은 어디에서나 사용할 수 있으며, 사용하지 않으면 전문 개발자라고 부를 수 없다고 말할 수도 있습니다. 혼자 개발하더라도 소스 제어는 여전히 몇 가지 이점을 제공합니다. 결국 그것은 역사와 광범위한 실행 취소 경로를 제공합니다. 또한 새 버전이 마음에 들지 않으면 항상 이전 버전으로 되돌릴 수 있다는 사실을 알고 더 많은 실험을 할 수 있습니다.

즉, Subversion 또는 Git과 같은 소스 제어 시스템 내에서도 워크 플로는 팀마다 크게 다릅니다. 시작하기 가장 좋은 곳은 아마도 소스 제어 시스템을 선택하고 표준 워크 플로우에 익숙해지는 것입니다 (전문적인 삶에서 워크 플로우를 전환해야 할 머리를 유지하십시오).

시작하려면 Git을 추천합니다. 나는 Git 팬이지만 Git gets를 선택하면 서버리스 작업으로 시작할 수 있으며 서버가 적합한 경우에만 서버를 설정할 수 있습니다. 반면 Subversion은 서버가 필요하며 서버를 설정하는 것은 어렵지 않지만 매우 어려운 것은 아니지만 이런 종류의 일에 익숙하지 않을 때는 어려운 일입니다.

다음은 일반적인 소스 제어를위한 몇 가지 유용한 규칙에 대한 개요입니다. http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

혼자서 작업 할 때는 많은 작업 흐름이 필요하지 않습니다. 일찍 커밋하고 자주 커밋하십시오. 버전 출시를 시작하면 릴리스에 태그를 지정하십시오. 실험이나 긴 발산 작업을위한 브랜치를 생성하십시오 (Git은 Subversion보다 저렴하고 간단합니다).

매우 간단한 수준의 소스 제어 시스템 (SVN, Git 등)을 사용하면 파일의 변경 기록을 유지할 수 있습니다. 이를 통해 시간이 지남에 따라 코드가 어떻게 변경되었는지 확인하고 원하지 않는 변경 사항을 롤백 할 수 있습니다 (예 : 변경이 예상대로 작동하지 않고 코드를 이전에 알려진 상태로 되돌릴 수 있음). 이것은 당신이 그것을 사용하기 시작하면 스스로 개발하더라도 당신에게 귀중한 것이 될 것입니다.

팀의 다른 사람과 작업하는 즉시 여러 사람이 동일한 파일을 변경할 수 있고 변경 사항이 충돌하지 않는 경우 (예 : 두 사람이 파일의 다른 섹션을 변경하는 경우) 변경 사항이 병합되므로 혜택이 훨씬 더 커집니다. 자동으로. 충돌이있는 경우 동료 옆의 변경 사항을보고 변경 사항을 병합하는 방법에 대해 논의 할 수 있습니다.

또한 코드 버전을 릴리스 할 때 코드베이스 (일반적으로 태그라고 함)의 스냅 샷을 작성하여 주 소스가 아직 릴리스되지 않았을 수있는 새로운 기능으로 이동하더라도 문제점을 쉽게 디버그 할 수 있습니다.

다음은 유용한 리소스입니다.

Visual Studio 및 .NET을 사용하여 Subversion 및 Tortoise SVN 시작 및 실행

Subversion을 사용한 버전 제어

초보자를위한 튜토리얼

매우 기본적인 수준에서 시작하는 데 도움이되는 훌륭한 자습서 (비디오 및 텍스트)가 있습니다. Git은 초보자에게 처음으로 이유를 알려주고 반복, 정의 및 그래픽을 사용하여 주요 명령의 이름과 기능을 기억하는 데 도움이되는 초보자에게 부드러운 주제로 주제 를 소개 하는 데 큰 접근 방법이있는 것 같습니다 .

SVN

SVN은 CVS를 더 잘 수행하도록 의도되었습니다. CVS (Concurrent Version System)는 한 번에 파일 작업을 수행했으며 SVN은 일반적으로 한 번에 디렉토리 또는 디렉터리 트리 작업을 수행했습니다. SVN (및 CVS 또는 기타 시스템)은 직장에서 사용하는 경우 중요 할 수 있지만, 우리는 늦은 모델을 선호하는 것처럼 몇 년마다 소스 제어를 수행하는 데 필요한 것에 대한 이해를 크게 향상 시킨다고 생각합니다. 컴퓨터의 경우 최신 모델 소스 제어 도구를 선호해야합니다. 많은 시스템의 경우 코드를 마이그레이션 할 수있는 변환기와 폐기 된 시스템에서 생성 된 히스토리 및 기타 아티팩트가 있지만 시스템을 변경하는 것은 막대한 투자이며 코드 히스토리가 손실 될 수 있습니다.

전문적인 소스 제어로 전문적인 요구 사항 충족

귀하의 질문 "프로젝트 요구를 충족시키기 위해 GIT 및 Subversion과 같은 전문가 용 도구를 어떻게 사용합니까?" "가능한 한 빨리 일하면서 팀이 서로의 방식으로 협력하지 않고 어떻게 협력 하는가?"라는 질문과 밀접한 관련이 있습니다.

코드는 다른 개발자가 사용할 코드를 만드는 일부 개발자와 다른 수준의 안정성 대 혁신이 필요한 다양한 이해 관계자와 함께 자주 변경됩니다. 소스 제어 시스템은 팀이 사용할 코드를 저장하여 시간에 따라 변경되는 버전 및 종종 변경 그룹을 다른 변경 그룹에서 분리하는 데 사용되는 코드 사본으로 제어되는 브랜치와 함께 컨텍스트의 각 변경 사항을 유지합니다.

여러 팀 구성원의 작업을 병합하여 작업을 다시 가져 오는 것은 SVN 및 이전 시스템에서 중앙 집중화되어 어려운 작업이었습니다. Git을 사용하는 팀의 경우, 몇 명의 전문가 대신 팀 전체의 영향을 받기 위해 병합이 더 단순 해지고 더 쉽게 이루어집니다. SVN에서 브랜칭은 개인적인 문제가 될 수 있지만 병합은 종종 팀에 고통스러운 영향을 미쳤으며 코드를 기본 라인으로 다시 이동하는 것은 권한 부여, 중단 방지 및 작업에 필요한 노력의 수준에서 고통 스러울 수 있습니다. .

확립 된 소스 제어 저장소에서 전문가는 근본 원인의 문제점 진단과 같은 다른 요구를 충족시킬 수 있습니다. 작동하는 데 사용 된 코드 버전이 있고 현재 버전에서 발생하는 문제를 새로 발견 한 경우, 문제가 발생한 시점을 정확하게 찾아 내기 위해 히스토리에서 앞뒤로 이동할 수 있습니다. SVN 에서이 기능은 미숙하지만 Git에서 마지막 작동 / 첫 번째 실패 버전에 대한 검색은 git bisect라는 명령으로 지원됩니다. 이 문제는 두 코드 사이의 소스 변경 중 하나에 의해 발생하며, 이는 전체 코드베이스를 검색하는 것보다 훨씬 쉽게 진단 할 수 있습니다.

유감스럽게도 소스 컨트롤을 사용하는 데 도움이되기를 바랍니다.

우리 팀은 자체 개발 한 팀 버전 관리 시스템을 사용합니다. (슬프게도, Git은 아직 IBM i "네이티브"소스 파일에서 작동하지 않는 것 같습니다.) 개인적으로, 해당 시스템에서 소스를 가져온 후에는 프로젝트가 완료 될 때까지 개발 과정에서 Git을 사용합니다. 팀 VCS.

그들이 투표에서 말한 것처럼 ... 일찍 저지르고 자주 저 지르십시오. 새로운 기능을 다룰 때 커밋합니다. 테스트와 디버깅 중에 변경을 할 때마다 컴파일간에 커밋하고 컴파일러 오류를 수정하려고 할 때마다 커밋합니다. 이를 통해 테마에서 여러 변형을 시도하는 것이 더 간단 해지며 필요한 경우, 특히 여러 파일에서 변경 사항이 조정될 때 테마에서 쉽게 취소 할 수 있습니다.

힘내 내가 개발 접근 방식을 개선했다.