약간의 맥락 : 저는 대학 3 학년입니다. 학생들은 4 명의 팀으로 나뉩니다. 거의 모든 사람들이 창문 아래에서 일하게 될 것입니다 (리눅스에있는 나와 같은 몇몇 사람은 제외). 학교 커리큘럼의 일환으로, 우리는 곧 실제 고객을위한 프로젝트 작업을 시작할 것입니다. 그러나 저와 다른 팀은 코드를 서로 공유하기에 가장 좋은 방법이 궁금합니다.
저는 3 년 동안 아르바이트를 해왔으며 다른 프로젝트에서 git과 mercurial을 모두 사용한 경험이 많으므로 한 시스템을 사용하는 데 아무런 문제가 없습니다. 그러나 내 팀원 중 누구도 이전에 버전 제어 시스템을 사용한 적이 없습니다. SVN을 사용해 보았지만 큰 문제가 있었고 다른 것을 시도하는 것을 선호하는 다른 팀도 있습니다. 그래서 그들은 내 의견을 요청했습니다.
내 생각 : 나는 수은 + TortoiseHg가 창문 아래에서 더 잘 통합된다고 들었지만 익명의 머리 개념이 설명해도 혼란 스러울 지 궁금합니다. 반면에, git 브랜치는 초보자가 이해하기 쉽지만 (각 프로그래머의 명확한 작업 분리) 창에서는 잘 작동하지 않는다는 것을 알았습니다.
답변
의심의 여지없이 Mercurial.
물론 이것은 주관적이며, 한 사람에서 다른 사람으로의 초심자이지만, 일반적인 의견은 Mercurial이 VCS를 처음 접하는 사람이나 이전 세대 VCS 중 한 사람으로부터 온 사람에게 쉽게 접할 수 있다는 것입니다.
손에 든 포인트 :
-
Mercurial은 Windows를 염두에두고 개발되었습니다 . 힘내는 포팅되었다. 누군가 나에게 무엇을 말하려고하더라도 Git은 여전히 Windows에서 두 번째로 높은 시민입니다. 지난 몇 년 동안 상황이 확실히 개선되었지만 * nix 상자에서와 같이 Windows에서 왜 작동하거나 작동하지 않는지에 대한 논쟁이 여전히 많이 있습니다. TortoiseHg는 매우 훌륭하게 작동하며 워크 플로를 중단하지 않고도 Visual Studio 구현을 훨씬 쉽게 사용할 수 있습니다.
-
누군가가 “당신보다 Git이 더 강력합니다 …”라는 토론을 시작하면 그는 거의 모든 것을 말합니다. 사용자의 95 %는 Mercurial이 더 직관적 인 것 같습니다. 인덱스가 부족한 것부터보다 직관적 인 옵션 (옵션 스위치는 일관된), SHA1 해시 대신 커밋을위한 로컬 번호 (SHA1 해시가 사용자 친화적이라고 생각한 적이 있는가 ???)
-
Mercurial의 지점은 Git의 지점보다 강력하지 않습니다. 차이점을 설명하는 게시물. 이전 개정으로 돌아가는 것은 “이전 개정 업데이트”만큼 간단합니다. 거기에서 시작; 새로운 커밋을 수행하십시오. 명명 된 분기를 사용하려는 경우에도 사용할 수 있습니다.
자, 이것들은 모두 세부 사항이며, 배울 수 있고 모든 것을 알 수 있지만 문제는 … 이것들이 합쳐집니다. 그리고 결국, 하나는 다른 것보다 단순하고 직관적 인 것처럼 보입니다. 그리고 버전 관리 시스템은 학습에 시간을 소비하는 것이어서는 안됩니다. 프로그래밍을 배우고 프로그래밍을해야합니다. VCS는 도구입니다.
참고로; 매일 Git과 Mercurial을 사용합니다. 둘 중 하나를 사용하는 데 문제가 없습니다. 그러나 누군가가 추천을 요청하면 항상 Mercurial을 추천합니다. 그래도 처음 손에 들어 왔을 때 매우 직관적 인 느낌이 들었습니다. 내 경험상 Mercurial은 Git보다 분당 WTF가 적습니다.
답변
TortoiseHg UI가 Windows에서 훌륭한 경험이라는 것을 알았습니다. 과거에 Git을 실험 할 때 대신 명령 줄로 이동했습니다. 평범한 사용자에게는 좋은 UI가 명령 줄보다 훨씬 접근하기 쉽습니다. 따라서 Mercurial을 사용하는 것이 좋습니다. (워크 벤치 창에 멋진 분기 그래프도 포함되어 있습니다. 기본적인 분기 문제를 해결해야합니다.)
일단 UI 관점에서 사물을 이해하면 명령 줄로 가서 스크립트를 작성하거나 수동 작업을 수행 할 수 있지만 반드시 그럴 필요는 없습니다.
답변
세 번째 옵션에 관심이 있다면 화석을 제안 합니다. 코드를 공유하기 위해 임시 웹 서버를 던지는 기능이 소규모 프로젝트에서 훌륭하게 작동한다는 것을 알았습니다. Fossil은 실행 파일 일 뿐이므로 소스와 소스를 썸 드라이브에 넣고 모든 대학 컴퓨터에서 사용할 수 있습니다.
fossil ui동료 학생들이 나와 동기화 할 수있는 위치에 임시 웹 서버를 시작하는 데 사용하십시오 . 또한 티켓 시스템, 위키 및 브랜치 변경 및 커밋 태그 지정을위한 사용하기 쉬운 웹 인터페이스를 제공합니다.
그냥 확인 그들은 읽기 빠른 시작 가이드 , 및 / 또는 책 . 마지막으로, 웹 UI보다 친숙한 사용자 인터페이스를 제공하는 winFossil 이라는 프로젝트가 있습니다.
답변
팀이 버전 제어에 익숙하지 않고 많은 사람들이 Windows를 사용하고 있다고 가정하면 git보다 수은을 권장합니다.
git과 mercurial이 사용하는 버전 제어의 개념 모델은 매우 유사하므로 일단 마스터하면 다른 것을 쉽게 선택할 수 있습니다 (유사한 이유로 저장소를 다른 저장소로 변환하는 것은 매우 쉽습니다) . 이것은 나중에 마음이 바뀐다면 큰 의미가 없습니다.
제 생각에 수은은 새로운 사용자가 배우기 쉽습니다. 단순하고 쉬운 일을 어렵게 만듭니다. 힘내 위험한 작업을 쉽게 만듭니다 (쉽게 수행하기 쉽지만 반드시 올바르게 수행하기는 쉽지 않습니다!)
Winodows에 대한 TortoiseHg 인터페이스도 매우 훌륭하며, 수은 사용을 선호하는 또 다른 주장입니다.
답변
답변
많은 사람들이 제안했듯이 TortoiseHg 를 통한 Mercurial 은 진입 장벽이 매우 낮습니다.
Windows 사용자에게는 두 개의 설치 프로그램이 아닌 단일 설치 프로그램 (및 배우고 싶지 않을 수도있는 전체로드)이며 THg 사용자 인터페이스는 TortoiseGit + Msysgit 보다 훨씬 세련 됩니다.
익명의 머리
익명의 머리가 혼란 스러울 것이라고 생각되면 사용을 장려하지 마십시오. 대부분의 hg책은 균형 잡힌 접근 방식을 취하고 토폴로지 및 명명 된 브랜치를 모두 가르치고 독자가 자신에게 가장 적합한 것을 결정하게합니다.
명명 된 지점
내가 정말로 놓친 것 중 하나 git는 hg‘ named branches ‘ 이므로 한 가지 옵션입니다. git브랜치는 작업하는 동안에는 문제가 없지만 해당 작업을 다른 브랜치로 병합하면 해당 변경에 대한 컨텍스트가 많이 손실됩니다.
에서 hg당신이라는 지점을 만들 수 Jira#1234항상 그와 관련된 개정의 모든 찾을 수 수정 . 에서 git지점이 병합되고 참조가 삭제되면 수정 트리의 토폴로지에서 수정의 일부인 수정을 추론해야합니다. 참조를 삭제하지 않더라도 해당 분기의 마지막 커밋 만 알 수 있으며 그 조상 중 어떤 것이 해당 커밋 체인의 일부인지 알 수 없습니다.
북마크
또는 명명 된 분기를 사용하지 않고 git익명 분기와 스타일 워크 플로를 원하는 경우 책갈피를 대신 사용할 수 있습니다 .
이것은 두 세계에서 가장 좋을 수 있습니다. git워크 플로 를 배우지 만 더 간단한 hg명령 을 사용하게 됩니다.
인덱스 / 캐시 / 스테이징 영역
개인적으로, 나는 학생들이 익명의 머리 git보다 인덱스 / 캐시 / 스테이징 영역에 혼동 될 가능성이 훨씬 높다고 생각 hg합니다. hg커맨드 라인 에서이 고급 기능을 선택적으로 사용하는 것을 선호하지만 , git항상 사용하고 싶다고 가정합니다.
또한 스테이징 영역은 테스트되거나 컴파일되지 않은 커밋을 권장한다고 생각합니다. 나는이 있었 근무했던 장소의 많은 때문에 그것을 컴파일하지 않는 경우 커밋하지 않는 내가 차라리 것, 규칙이 보류은 / 숨겨 놓은 내가 지금 원하는 다시 실행 단위 테스트와 버전이 커밋하지 않는 변경 나는 컴파일을 안다.
나중에 hg bisect 또는 git bisect을 사용하여 버그를 추적 할 때 컴파일하는 개정판뿐만 아니라 모든 개정판을 테스트 할 수 있음을 스스로에게 감사하게 될 것입니다.