나는 자신을 포함하여 이전에 아무도 소스 컨트롤을 사용한 적이없는 부서에서 일하고 있습니다.
나는 개념을 추진하려고합니다. SVN을 연구하는 동안 약간의 시간을 보냈습니다. 나는 몇 가지 기본 사항을 배웠다. 커맨드 라인과 Tortoise에서 생성 / 업데이트 / 체크 아웃 / 커밋 할 수 있습니다. 태그와 브랜치 방법을 배우기 시작했지만 여전히 브랜치와 트렁크 간의 충돌에 대해 많은 혼란을 겪고 있습니다. 아직 배우고 있지만 물리적 인 사람은 없습니다. 그것은 모두 책 / 자습서와 시행 착오에서 나온 것입니다.
내가 온라인에서 읽은 것에서 git알면 좋을 것 같지만 더 복잡합니다. 나는 자신을 압도하고 싶지 않습니다. git으로 이동하기 전에 svn을 계속 마스터해야합니까, 아니면 지금 git으로 점프하는 것이 더 현명합니까?
두 가지 접근 방식에 장단점이 있습니까?
답변
아니
힘내는 SVN과 크게 다르므로 도움이되지 않습니다. “update”및 “commit”명령을 찾고 왜 모든 것이 다른지 궁금 할 것입니다.
Bottom Up에서 Git으로 시작하여 거기서 시작하십시오 .
표준 중앙 집중식 업데이트 / 커밋 패턴 버전 관리 시스템을 Git과 대조하는 것은 버스를 대중 교통과 비교하는 것과 같습니다. 버스는 똑같은 경로를 사용하여 A 지점에서 B 지점으로 당신과 다른 모든 사람들을 데려 갈 것입니다. 대중 교통을 이용하면 원하는 경로를 사용하여 A 지점에서 B 지점으로 이동할 수 있습니다.
분산 자체에는 알아야 할 단점이 있습니다. 모든 사람을 같은 페이지에 유지하려면 더 많은 작업이 필요합니다. 그러나 유연성이 크게 향상되었습니다.
수정 해시 대 숫자
누군가는 SHA1 해시를 사용하는 Git을 언급했지만 Hg는 숫자를 사용합니다.
먼저 매일 커밋 / 풀에서 해시를 직접 처리 해야하는 경우는 거의 없습니다. diffs 또는 더 까다로운 rebasing 항목을 수행하는 경우 로그를 풀고 해시를 가져와야합니다.
Git을 사용하면 모든 사람이 동일한 해시를 갖습니다. 다른 리포지토리에는 다른 커밋 번호가 없으며 모든 사람이 같은 페이지에 있습니다. Hg를 사용하면이 정도는 줄어 듭니다. 실제로 커밋 해시를 가져 와서 코드 타임 라인을 비교하거나 통과하기 위해 처리 해야하는 경우 숫자 대신 해시가있을 때 다른 사람들과 동기화하는 것이 더 쉽습니다.
답변
아니, 귀찮게하지 마십시오.
DVCS부터 시작하십시오. SVN이 인기가 있다는 사실이 표준이 아닙니다. Linus Torvalds는 뇌가 썩을 수 있다고 말합니다 .
Joel Spolsky의 Subversion Re-education 이라는이 훌륭한 기사 / 소개를 읽으십시오 .
이 다른 질문을 읽고 싶을 수도 있습니다. 저는 Subversion 괴짜입니다. 왜 Mercurial이나 Git 또는 다른 DVCS를 고려해야합니까?
DVCS 사이에서 선택
개인적으로 저는 수은과 자식을 모두 사용하며 둘 다 아는 것이 중요하다고 생각합니다. 이에 대한 권장 자료는 Git vs. Mercurial : Please Relax (git-addremove 예제 참조)입니다. 그 기사에서 인용 한 두 따옴표는 요약합니다.
자식에 관해서 :
Git의 디자인 철학은 Unix의 철학입니다. Subversion, CVS 또는 Mercurial과는 달리 git는 단일체 바이너리가 아니라 git-pull, git-merge, git-merge, git-apply, git-hash-object 및 git-merge-file과 같은 하위 수준의 “배관”명령에 대한 git-checkout 따라서 MacGyver와 마찬가지로 Git으로 필요한 모든 작업을 수행 할 수 있습니다. 여기에는 완전히 멋진 Wiki 엔진, 이슈 트래커, 파일 시스템, sysadmin 도구 등 퓨즈 수리가 부족한 모든 것이 포함됩니다.
수은 관련 :
시스템을 깨끗하게 유지하려는 개발자는 아마도 git이 git을 구성하는 144와 대조적으로 hg가 하나의 바이너리를 설치한다는 사실에 감사 할 것입니다. 단순성 hg는 특정 기능을 생략하여 제공합니다.
github에서 많은 프로젝트를 찾을 수 있으며 git은 더 강력하지만 새로운 사용자, 특히 Windows 사용자에게는 다소 위협이 될 수 있습니다. 비트 버킷 도 있습니다 (github은 수은과 동일합니다).
나의 추천 : 수은으로 시작하고 편안하게 느끼면 git을 선택하십시오. 도구에 관한 것이 아니라 함께 일하는 사람들에 관한 것입니다 .
내가 Subversion의 실제적이고 실제적인 사용을 고려하는 것은 다른 사람들과의 작업이 아니라 프로덕션 응용 프로그램에 대한 업데이터를 구현하는 것입니다. 이유는 다음과 같습니다.
- 현재 svn은 대부분의 호스팅 제공 업체에 거의 설치되어 있습니다
- 좋은 하위 프로젝트 지원이 있습니다 (git 및 hg로 해결 가능).
svn up프로젝트와 그 의존성이 업데이트됩니다.
DVCS는 Subversion에 있으며 Bittorrent는 ftp에 있습니다.
편집 : Git 전에 알아야 할 VCS가 있다면 Mercurial 일 수 있습니다 (더 친숙한 CLI 인터페이스이며 분산 개념을 도입하는 것이 좋습니다). 이 조언은 CLI가 어느 정도 유사하기 때문에 Subversion에서 온 사람들에게 특별히 적용됩니다. 분산 버전 제어는 중앙 집중식 버전 제어보다 배우기 쉬울 수 있습니다. 클라이언트와 서버 부분이 아닌 저장소 인스턴스에 대해서만 걱정하기 때문 입니다.
답변
사용하고자하는 것을 배워야합니다. Guri는 Mercurial이 인기를 얻은 것처럼 인기가 있습니다. Git / Mercurial은 모두 분산 소스 제어 시스템입니다.
팀에 새로운 개념을 도입 할 때 가장 중요한 것은 (그리고 버전 관리가 너무 많은 팀의 새로운 주제로 간주되는 것은 불행한 일입니다.) 목표와 평가 기준을 설명하는 데 도움이됩니다. 공식적인 내용 일 필요는 없지만 다음과 같은 질문을 해보십시오.
- 우리 팀 의 버전 관리 목적은 무엇입니까? 예, 모든 가치가있는 모든 버전 제어 시스템을 사용하면 기록으로 돌아가 특정 파일에서 변경된 내용을 확인할 수 있습니다. 그러나 새 릴리스의 기준선으로 사용 하시겠습니까? (머리를 끄덕이고, 당신은 이것을 원합니다). 이것은 달성하고자하는 것에 대한 2-3 줄 비전 진술입니다.
- 귀사의 팀은 나중에 업무를 신중하게 병합하기 위해 자체 지역 업무 환경을 갖추고 있습니까? 그렇다면 DVCS 경로가 가장 적합 할 수 있습니다.
- 반대로, 팀이 하나의 공유 드라이브에서 작업하는 데 익숙하고 모든 것이 지속적으로 통합되어 있습니까? 그렇다면보다 전통적인 VCS가 가장 적합 할 수 있습니다.
대안을 평가할 때 모든 VCS가해야 할 중요한 일을 고려해야합니다.
- 기준 코드 (태그, 레이블 등). 기본적으로 프로젝트 릴리스에 사용 된 정확한 소스 코드를 얻는 방법은 무엇입니까?
- 중앙 서버에 대한 로컬 변경 사항을 가져옵니다. DVCS를 사용하든 표준 VCS를 사용하든 관계없이 코드의 권한있는 사본이 있어야합니다. 각 도구는이 프로세스를 다르게 처리합니다.
- 중앙 서버에서 로컬 사본으로 변경 사항을 가져 오십시오.
- 실험적인 변화를 다루는 방법. VCS를 사용하면 기본 프로젝트 소스 코드를 손상시키지 않으면 서 제안 된 변경 사항을보다 대담하게 처리 할 수 있습니다. DVCS와 표준 VCS 시스템은 이와는 매우 다른 방식으로 접근합니다. 그 중 하나가 팀에 가장 적합합니다.
- 서버를 어떻게 설정하고 구성합니까?
- 인증이 필요하십니까? 그렇다면 실제로 변경할 수있는 사람 만 실제로 할 수 있도록하려면 어떻게해야합니까?
결국 표준 VCS 또는 DVCS 시스템이 팀에 가장 적합한 지 여부를 결정하기 위해 빠른 평가를 수행하십시오. 통증이 가장 적은 도구를 선택해야합니다. 그렇지 않으면 도구가 채택되지 않을 것입니다. 그런 다음 요구 사항에 가장 적합한 대안을 평가하십시오.
결국, 당신이 사용하려는 것을 배우십시오.
답변
많은 사람들이 git이 svn보다 복잡하다고 생각합니다. 서브 버전 (또는 cvs 등)을 잠시 사용한 후에는 모드를 DVCS 모델로 정신적으로 전환하기가 어려울 수 있습니다. 이를 바탕으로 git과 같은 DVCS를 연구하면서 서브 버전과 같은 전통적인 VCS를 연구하는 것이 당신에게 좋지 않을 수 있습니다.
git이 내가 선호하는 VCS이지만 서브 버전을 배우는 것이 가장 좋습니다. 하나는 여전히 많은 서브 버전과 cvs 리포지토리가 있기 때문에 언젠가는 상호 작용해야 할 수도 있고 기존 VCS에 비해 DVCS의 정확한 장단점을 더 잘 이해할 수 있다는 것입니다.
답변
svn을 배우고 git을 배우는 것은 비생산적입니다.
몇 가지 이유는 다음과 같습니다.
- svn과 근본적으로 다른 Gits. Git은 혼란스럽고 svn은 클라이언트 / 서버입니다.
- 같은 단어에 다른 의미가 붙습니다. 예를 들어 ‘git checkout …’은 ‘svn checkout …’과 다른 의미를 갖습니다.
- 분기가 다릅니다. Git은 svn이 지원하지 않는 저렴한 현지 지점 인 ‘주제’지점이라는 개념을 가지고 있습니다.
- Git은 작업 트리와 리포지토리 사이에 인덱스라는 추가 위치가 있습니다. Svn에는 색인이 없습니다. git을 사용하면 변경 사항이 작업 트리에서 색인으로 리포지토리로 이동합니다.
내 조언은 git을 배우는 것입니다.
답변
GIT와 SVN에는 광범위하게 동일한 것이 있지만 그렇지 않은 것도 있습니다.
작성 / 업데이트 / 체크 아웃 / 커밋
대체로 동일하게 쉽게 집어 올릴 수 있습니다.
태그와 브랜치 태그를 지정하지만 브랜치와 트렁크 등의 충돌에 대해 여전히 혼란 스럽습니다.
둘 사이에 다릅니다.
지금 당장 바꾸어야한다고 말하지 말고 (나는 그것이 당신의 전화라고 생각합니다), 그것을 고려해야 할 것으로 지적하고 싶었습니다. Git을 사용 해보고 싶다면 SVN에서 Git과 다른 것을 배우기 위해 지금 전환하기로 결정할 수 있습니다.
답변
와우; 12 답변과 모든 사람이 여전히 질문을 구걸하고 있습니다 …
아니요, Subversion은 Git의 전제 조건이 아닙니다.
Subversion과 Git 사이에 명확한 매핑은 없습니다. 둘 다 배우려고한다면, 다른 행동에 대해 동일한 용어를 사용한다는 사실만으로도 어려움을 겪을 것입니다. (그리고 같은 행동에 대해 다른 용어)
svn commit와는 다른 것git commit입니다.- svn과 git의 분기는 매우 다릅니다
- svn 저장소는 git remote와 비슷하지만 실제로는 아닙니다.
- 자식 저장소는 svn 작업 복사본과 비슷하지만 실제로는 아닙니다.
이들은 공통 언어로 나눈 두 가지 도구입니다.
귀하의 질문과 대부분의 다른 답변은 git이 일종의 svn ++라고 가정합니다. “더 나은 svn”. 그렇지 않습니다. 이 둘은 자동차와 오토바이처럼 같은 공간에서 작동하는 다른 도구입니다.
하나를 골라 마스터하고 팀에서 사용하는 것이 좋습니다. 이전에 사용하지 않은 사람들에게는 학습 버전 관리가 어려울 것입니다. VCS는 인프라의 중요한 부분이 될 것이며,이를 신뢰하는 법을 배우려면 새로운 작업 습관을 갖추어야합니다. 시간이 좀 걸립니다.
어느 쪽이든, sysadmins가 마스터 저장소를 백업하도록하십시오. 소스 제어를 잃는 것은 치명적입니다.