프로그래밍 학생들에게 어떤 DVCS (git 또는 hg)가 더 쉬운가요? [닫은]


25

약간의 맥락 : 저는 대학 3 학년입니다. 학생들은 4 명의 팀으로 나뉩니다. 거의 모든 사람들이 창문 아래에서 일하게 될 것입니다 (리눅스에있는 나와 같은 몇몇 사람은 제외). 학교 커리큘럼의 일환으로, 우리는 곧 실제 고객을위한 프로젝트 작업을 시작할 것입니다. 그러나 저와 다른 팀은 코드를 서로 공유하기에 가장 좋은 방법이 궁금합니다.

저는 3 년 동안 아르바이트를 해왔으며 다른 프로젝트에서 git과 mercurial을 모두 사용한 경험이 많으므로 한 시스템을 사용하는 데 아무런 문제가 없습니다. 그러나 내 팀원 중 누구도 이전에 버전 제어 시스템을 사용한 적이 없습니다. SVN을 사용해 보았지만 큰 문제가 있었고 다른 것을 시도하는 것을 선호하는 다른 팀도 있습니다. 그래서 그들은 내 의견을 요청했습니다.

내 생각 : 나는 수은 + TortoiseHg가 창문 아래에서 더 잘 통합된다고 들었지만 익명의 머리 개념이 설명해도 혼란 스러울 지 궁금합니다. 반면에, git 브랜치는 초보자가 이해하기 쉽지만 (각 프로그래머의 명확한 작업 분리) 창에서는 잘 작동하지 않는다는 것을 알았습니다.


2
git은 기본적으로 많은 힘을 가지고 있지만 수은을 배우는 것이 더 간단하다고 말한 모든 사람들은 두 가지를 모두 사용한 경험에 근거하여 동의하는 경향이 있습니다. 그리고 그렇습니다. 수은 도구는 Windows와 비교하여 git에 비해 쉽습니다. 즉, 사람들을 안내하고 첫 주 (또는 그 이상 ...) 자습서에서 그들을 가리킬 것으로 기대합니다.
wkl

1
처음부터 DVCS를 사용하는 것은 여러 명의 기여자가 병렬로 작업하는 기여를 병합하는 가장 간단한 방법 일 것입니다. 익명의 머리가 혼란 스러우면 사용하지 마십시오 (수은 지명 지사).
Stephen C. Steel

2
이 블로그 게시물에 다시 연결 하시겠습니까? 힘내는 해리 어 점프 제트 입니다.
sbi 2016 년

1
왜 "배우기가 너무 어렵다"는 문제가되는지 전혀 이해하지 못했습니다. 커밋과 브랜치 방법을 배우는 데 20 분이 걸리고 10과는 반대로 ... 큰 문제?
대안

1
그들 중 하나가 hginit.com을 통해 그들의 반응에 따라 행동 하는 것을 지켜보십시오 .
chelmertz

답변:


49

의심의 여지없이 Mercurial.

물론 이것은 주관적이며, 한 사람에서 다른 사람으로의 초심자이지만, 일반적인 의견은 Mercurial이 VCS를 처음 접하는 사람이나 이전 세대 VCS 중 한 사람으로부터 온 사람에게 쉽게 접할 수 있다는 것입니다.

손에 든 포인트 :

  1. Mercurial은 Windows를 염두에두고 개발되었습니다 . 힘내는 포팅되었다. 누군가 나에게 무엇을 말하려고하더라도 Git은 여전히 ​​Windows에서 두 번째로 높은 시민입니다. 지난 몇 년 동안 상황이 확실히 개선되었지만 * nix 상자에서와 같이 Windows에서 왜 작동하거나 작동하지 않는지에 대한 논쟁이 여전히 많이 있습니다. TortoiseHg는 매우 훌륭하게 작동하며 워크 플로를 중단하지 않고도 Visual Studio 구현을 훨씬 쉽게 사용할 수 있습니다.

  2. 누군가가 "당신보다 Git이 더 강력합니다 ..."라는 토론을 시작하면 그는 거의 모든 것을 말합니다. 사용자의 95 %는 Mercurial이 더 직관적 인 것 같습니다. 인덱스가 부족한 것부터보다 직관적 인 옵션 (옵션 스위치는 일관된), SHA1 해시 대신 커밋을위한 로컬 번호 (SHA1 해시가 사용자 친화적이라고 생각한 적이 있는가 ???)

  3. Mercurial의 지점은 Git의 지점보다 강력하지 않습니다. 차이점을 설명하는 게시물. 이전 개정으로 돌아가는 것은 "이전 개정 업데이트"만큼 간단합니다. 거기에서 시작; 새로운 커밋을 수행하십시오. 명명 된 분기를 사용하려는 경우에도 사용할 수 있습니다.

자, 이것들은 모두 세부 사항이며, 배울 수 있고 모든 것을 알 수 있지만 문제는 ... 이것들이 합쳐집니다. 그리고 결국, 하나는 다른 것보다 단순하고 직관적 인 것처럼 보입니다. 그리고 버전 관리 시스템은 학습에 시간을 소비하는 것이어서는 안됩니다. 프로그래밍을 배우고 프로그래밍을해야합니다. VCS는 도구입니다.

참고로; 매일 Git과 Mercurial을 사용합니다. 둘 중 하나를 사용하는 데 문제가 없습니다. 그러나 누군가가 추천을 요청하면 항상 Mercurial을 추천합니다. 그래도 처음 손에 들어 왔을 때 매우 직관적 인 느낌이 들었습니다. 내 경험상 Mercurial은 Git보다 분당 WTF가 적습니다.


4
+ "VCS는 도구"입니다. 나는 "작은 것"을 한 요소로 고려하지는 않았지만 여기저기서 작은 문제를 추가하면 문제가 될 수 있다는 것이 사실입니다.
Gregory Eric Sanderson

8
"버전 관리 시스템은 학습에 시간을 소비하는 것이어서는 안됩니다." 이것은 쓰레기입니다. 항상 도구를 배우는 데 시간을 보내야합니다. 컴파일러를 배우는 데 시간을 보냅니다. 그러나 VCS는 컴파일러만큼이나 프로그래밍을위한 중요한 도구입니다.
JesperE

9
+1. 특히이 상황에서 '창문의 2 등 시민'주장은 절대적으로 중요합니다.
tdammers

"WTF (s) / minute"에 대해 +1 ( osnews.com/story/19266/WTFs_m ). 이 아이들은 기술을 배워야합니다 :-)
Ross Patterson

1
@Mark는 용어 차이의 결과 일뿐입니다. Git의 브랜치는 실제로 이름 일뿐입니다.
대안

10

TortoiseHg UI가 Windows에서 훌륭한 경험이라는 것을 알았습니다. 과거에 Git을 실험 할 때 대신 명령 줄로 이동했습니다. 평범한 사용자에게는 좋은 UI가 명령 줄보다 훨씬 접근하기 쉽습니다. 따라서 Mercurial을 사용하는 것이 좋습니다. (워크 벤치 창에 멋진 분기 그래프도 포함되어 있습니다. 기본적인 분기 문제를 해결해야합니다.)

일단 UI 관점에서 사물을 이해하면 명령 줄로 가서 스크립트를 작성하거나 수동 작업을 수행 할 수 있지만 반드시 그럴 필요는 없습니다.


"콘솔 중독자"이기 때문에 Tortoise {Svn, Git, Hg} 앱을 사용한 적이 없었기 때문에 TortoiseHg에 분기 그래프가 있다는 것을 몰랐습니다. 나는 그것을 확인해야 할 것이다
Gregory Eric Sanderson

4

세 번째 옵션에 관심이 있다면 화석을 제안 합니다. 코드를 공유하기 위해 임시 웹 서버를 던지는 기능이 소규모 프로젝트에서 훌륭하게 작동한다는 것을 알았습니다. Fossil은 실행 파일 일 뿐이므로 소스와 소스를 썸 드라이브에 넣고 모든 대학 컴퓨터에서 사용할 수 있습니다.

fossil ui동료 학생들이 나와 동기화 할 수있는 위치에 임시 웹 서버를 시작하는 데 사용하십시오 . 또한 티켓 시스템, 위키 및 브랜치 변경 및 커밋 태그 지정을위한 사용하기 쉬운 웹 인터페이스를 제공합니다.

그냥 확인 그들은 읽기 빠른 시작 가이드 , 및 / 또는 . 마지막으로, 웹 UI보다 친숙한 사용자 인터페이스를 제공하는 winFossil 이라는 프로젝트가 있습니다.


화석에 대해 좋은 소식을 들었지만 안타깝게도 새로운 DVCS에 익숙해 질 시간이 없습니다. 나는 가장 일반적인 함정을 해결하는 방법을 이미 알고 있기 때문에 (가능한 경우) 익숙한 것을 사용하는 것을 선호합니다. 그러나 제안에 감사드립니다. 시간이되면 분명히 그것을 살펴 보겠습니다.
Gregory Eric Sanderson

+1; 화석은 거의 알려져 있지만, 작업을하고 있다는 자체 포함 (dvsc + 위키 + 항공권 + 웹 서버) 그래서 너무 쉽게 입니다 TRAC 또는 GitHub의 전체에 대한 진정한 대안.
Javier

그러나 화석은 깃이나 hg만큼 학생들의 이력서에서 잘 보이지 않을 것입니다.
Ian

Mercurial은 hg 서브 기능도 내장하고 있습니다. 물론 버그 트래커와 위키가 없습니다. 그러나 bitbucket.com도 있습니다
Johannes Rudolph

3

팀이 버전 제어에 익숙하지 않고 많은 사람들이 Windows를 사용하고 있다고 가정하면 git보다 수은을 권장합니다.

git과 mercurial이 사용하는 버전 제어의 개념 모델은 매우 유사하므로 일단 마스터하면 다른 것을 쉽게 선택할 수 있습니다 (유사한 이유로 저장소를 다른 저장소로 변환하는 것은 매우 쉽습니다) . 이것은 나중에 마음이 바뀐다면 큰 의미가 없습니다.

제 생각에 수은은 새로운 사용자가 배우기 쉽습니다. 단순하고 쉬운 일을 어렵게 만듭니다. 힘내 위험한 작업을 쉽게 만듭니다 (쉽게 수행하기 쉽지만 반드시 올바르게 수행하기는 쉽지 않습니다!)

Winodows에 대한 TortoiseHg 인터페이스도 매우 훌륭하며, 수은 사용을 선호하는 또 다른 주장입니다.



0

많은 사람들이 제안했듯이 TortoiseHg 를 통한 Mercurial 은 진입 장벽이 매우 낮습니다.

Windows 사용자에게는 두 개의 설치 프로그램이 아닌 단일 설치 프로그램 (및 배우고 싶지 않을 수도있는 전체로드)이며 THg 사용자 인터페이스는 TortoiseGit + Msysgit 보다 훨씬 세련 됩니다.

익명의 머리

익명의 머리가 혼란 스러울 것이라고 생각되면 사용을 장려하지 마십시오. 대부분의 hg책은 균형 잡힌 접근 방식을 취하고 토폴로지 및 명명 된 브랜치를 모두 가르치고 독자가 자신에게 가장 적합한 것을 결정하게합니다.

명명 된 지점

내가 정말로 놓친 것 중 하나 githg' named branches ' 이므로 한 가지 옵션입니다. git브랜치는 작업하는 동안에는 문제가 없지만 해당 작업을 다른 브랜치로 병합하면 해당 변경에 대한 컨텍스트가 많이 손실됩니다.

에서 hg당신이라는 지점을 만들 수 Jira#1234항상 그와 관련된 개정의 모든 찾을 수 수정 . 에서 git지점이 병합되고 참조가 삭제되면 수정 트리의 토폴로지에서 수정의 일부인 수정을 추론해야합니다. 참조를 삭제하지 않더라도 해당 분기의 마지막 커밋 만 알 수 있으며 그 조상 중 어떤 것이 해당 커밋 체인의 일부인지 알 수 없습니다.

북마크

또는 명명 된 분기를 사용하지 않고 git익명 분기와 스타일 워크 플로를 원하는 경우 책갈피를 대신 사용할 수 있습니다 .

이것은 두 세계에서 가장 좋을 수 있습니다. git워크 플로 를 배우지 만 더 간단한 hg명령 을 사용하게 됩니다.

인덱스 / 캐시 / 스테이징 영역

개인적으로, 나는 학생들이 익명의 머리 git보다 인덱스 / 캐시 / 스테이징 영역에 혼동 될 가능성이 훨씬 높다고 생각 hg합니다. hg커맨드 라인 에서이 고급 기능을 선택적으로 사용하는 것을 선호하지만 , git항상 사용하고 싶다고 가정합니다.

또한 스테이징 영역은 테스트되거나 컴파일되지 않은 커밋을 권장한다고 생각합니다. 나는이 있었 근무했던 장소의 많은 때문에 그것을 컴파일하지 않는 경우 커밋하지 않는 내가 차라리 것, 규칙이 보류은 / 숨겨 놓은 내가 지금 원하는 다시 실행 단위 테스트와 버전이 커밋하지 않는 변경 나는 컴파일을 안다.

나중에 hg bisect 또는 git bisect을 사용하여 버그를 추적 할 때 컴파일하는 개정판뿐만 아니라 모든 개정판을 테스트 할 수 있음을 스스로에게 감사하게 될 것입니다.


완료 후 git 브랜치를 삭제할 필요가 없습니다. 그것은 단지 관습입니다. 또한 인덱스 사용을 잘못 해석하는 경우 -1-잘못된 커밋을 준비하는 데 사용하지 않고 일련의 커밋의 일부 단계 를 준비하는 데 사용합니다 . 일반적으로 히스토리를 정리할 때 리베이스 중에 발생합니다.
대안

@mathepic-분기 이름을 삭제하지 않고 모든 로컬 '수정'분기를 원격으로 푸시하면 많은 오래된 분기로 끝나는 것처럼 수많은 참조가 발생합니다. svn. 에서 hg당신이 그들을 찾을 경우에만 그들을 볼 수 있도록이 지점 이름, 항상 위상 적 지역이다.
Mark Booth

@mathepic-당신의 -1에 관해서는, 내가 말하는 것을 잘못 해석하고 있다고 생각합니다. 왜 누군가가 의도적으로 나쁜 커밋을했는지 상상할 수 없지만 git을 사용하면 실수로 쉽게 수행 할 수 있습니다. 해당 파일이 파일 c에서 수정 된 인터페이스를 구현 i하고 실수로 i없이 커밋 하면 잊어 버린 c경우 c컴파일 을 커밋하기 전에 변경 사항을 가져 오면 실패합니다. stash / compile / commit 워크 플로우를 대신 사용하면, 자신의 빌드가 먼저 중단되므로이 실수는 발생하지 않습니다. 그래도 대답을 명확하게하려고 노력했습니다.
Mark Booth
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.