혼자 개발자로서 Mercurial을 어떻게 사용합니까?
저는 소규모 개인 프로젝트에 Mercurial을 사용하기로 결정했습니다.
내가 읽은 대부분의 도움말은 여러 사용자 사례 변경 사항에 대해 설명합니다. 내가 솔로이기 때문에 그런 일이 일어나지 않을 것입니다.
여러 저장소가 늘어 났습니까? 내 개발 컴퓨터는 이미 Windows Home Server에 야간에 백업되어 있으므로 백업 목적으로 다른 곳에 두 번째 저장소를 두는 것은 가치가 없어 없어요.
매일 분기해야할까요? 아니면 전후? 아니면 언제?
일반적으로 Mercurial을 사용하는 고독한 개발자에게 권장하는 방법은 무엇입니까?
Mercurial을 사용하여 codeplex에서 호스팅되는 단위 테스트 프레임 워크 인 FsCheck를 개발했습니다. 나는 현재 유일한 개발자이지만 사람들은 나에게 패치를 보냅니다.
본문으로 내 파일 시스템에 "FsCheck"라는 폴더가 하나 있습니다. 여기에는 저장소가 하나 있으므로 main이라는 폴더가 있습니다. 일반적으로 특정 기능 기능이나 버그 수정 또는 버그 이스케이프 예외 및 feat-statefulchecking 및 patch-userFoo와 같은 작업을 수행하는 폴더가 몇 개 있습니다. 사용하여 생성됩니다.
기능이나 버그 수정이 해당 폴더의 모든 것을 커밋하고 메인으로 푸시합니다. main에서 병합 할 수 있습니다. (hg 커밋, hg 푸시, hg 병합). 그런 다음 폴더를 삭제합니다 (hg status 및 hg outgoing을 사용하여 유용한 것을 버리지).
최종 정리 (문서화)를 수행하는 릴리스 직전을 제외하고 거의 메인에서 작업하지 않습니다. 릴리스 전에는 릴리스 번호 (hg tag v0.5.1)로 main에 태그를 지정합니다.
Codeplex는 svn을 소스 제어로 사용합니다. 저는 로컬로 체크 아웃 된 SVN 복사본을 사용하는 릴리스를 저장하는 용도로만 사용하고 hg 아카이브를 사용하여 Mercurial 저장소를 복사합니다. 그런 다음 svn을 사용하여 커밋하십시오. (창에서 Mercurial을 SVN '슈퍼 클라이언트'로 사용하는 것은 아직 사용자가 사용할 수 없습니다.)
아직 이전 릴리스에 대한 유지 관리를 수행 할 필요가 없었지만 해당 릴리스의 개정판에서 주 저장소를 복제하여 (태그를 지정하기 때문에 간단합니다) 별도의 저장소에서 작업합니다. 메인 메뉴로 다시 병합하는 것 변경 사항을 메인으로 병합하고 병합하는 것만 큼 수납.
요약해서 기재 :
- 프로젝트 이름과 함께 모든 프로젝트의 저장소를 하나의 폴더
- 이 폴더에서 하나의 기본 저장소와 "작업 단위"당 하나의 임시 저장소 (작업 단위에 대한 설명 이름 포함).
브랜치와 작업중 인 작업이 파일 시스템에서 다운으로 볼 수 있기 때문에 좋습니다.
귀하의 질문이 표현 된 방식으로 볼 때 버전 관리 용어와 관련된 오해가있을 수 있습니다.
프로젝트마다 하나의 저장소가 있어야합니다. 저장소는 파일 시스템의 폴더로 생각할 수 있습니다. 특정 폴더에서 Mercurial 저장소를 초기화하면 해당 폴더 및 하위 폴더의 모든 파일을 저장소에 추가하여 버전을 제어 할 수 있습니다. 반드시 모든 것을 추가 할 필요는 없습니다.
원하는 경우이 로컬 저장소를 백업 형식으로 또는 다른 사람과 코드를 공유하는 방법으로 원격 저장소로 푸시 할 수 있습니다. 그러나 경우에는 특히 백업 솔루션이 이미 준비되어 있으므로 필요하지 않을 가능성이 있습니다.
분기는 일반적으로 프로젝트의 서로 다른 "버전"을 분리하는 데 사용됩니다. 일부 사람들이 언급했듯이 여기 코드를 리팩토링하는 방법을 시도하거나 특정 문제에 대한 다른 접근 방식을 테스트하는 솔로 개발자로서 개발자로서 할 수 있습니다. 작동하지 않는 롤백 할 위치가 없습니다. 지점에 불을 붙이면됩니다. 작동 전화기 브랜치를 메인 저장소 ( "트렁크")로 다시 병합하고 계속 진행합니다.
코드를 "릴리스"하는 지점에 도달해야 이전 버전을 계속 유지하는 경우 브랜치를 사용하는 것이 좋습니다. 예를 들어 버전 1.0을 출시하고 일부 사람들이이를 사용하기 시작 가정 해 있습니다. 그들이 그것을 사용하는 동안, 당신은 새로운 리포지토리에 기능을 추가하면서 다음 릴리스, 아마도 1.1을 향해 개인적으로 계속 작업합니다. 이제 누군가가 릴리스 된 1.0 코드에서 수정해야하는 버그를 발견했지만 릴리스 할 상태가 아니기 때문에 제공에서 수정하고 해당 코드를 할 수는 없습니다. 이것이 1.0 브랜치가 유용한 곳입니다. 1.0 브랜치에서 버그를 수정하고 병합하여 버그도 될 수 있습니다. 그런 다음 버그 수정으로 1.0을 다시 패키징하여 사용자에게 수 있습니다.
그 외에는 일반적으로 Mercurial 솔로를 사용하는 것과 관련된 멋진 작업이 많지 언어입니다. 몇 가지 작업을 수행하고 기능을 완료하면 필요한 경우 나중에 다시 돌아올 수있는 "체크 포인트"를 자신에게 제공하도록 커밋합니다. 저축 할 때마다 커밋 할 필요가 없습니다. 뭔가 중요한 것을 추가합니다. 이것은 당신이 할 수있는 볼 필요가있는 당신에게 프로젝트의 멋진 역사를 줄 것입니다.
자세한 내용 은 Mercurial을위한 분산 개정 제어 책을 읽어 보는 것이 좋습니다 . 고급 주제를 읽을 수 있습니다. 1-5 장과 8 장을 보급면 Mercurial 및 일반적으로 버전 관리에 좋은 소개를받을 수 있습니다.
Mercurial 이외의 다른 분산 제어 시스템을 사용하지만 중요하지 않습니다.
솔로 프로젝트에서는 상당히 많이 사용합니다. 저는 일반적으로 항상 작동하는 버전을 가지고 있어야하는 메인 개발 브랜치 ( "트렁크")를 가지고 있습니다. 모든, 단위 테스트 및 기타 자동화 된 테스트를 통과하고 테스트 범위에서 명시 적으로 코드 제외 된 작은 비트를 제외하고 모든 코드가 테스트에 의해 테스트 즉 것을 의미합니다. 이것은 항상 좋은 모양을 유지하도록 보장합니다.
변경 작업을 시작할 때마다 분기에서 새 분기를 만듭니다. 이를 통해 자유롭게 해킹 할 수 있습니다. 예를 들어이 분기에서 통과하는 자동화 된 테스트에 대해 걱정하지 않아도됩니다. 격리 된 영역이기 때문에 원하는만큼 자주 커밋 할 수 있습니다. 마이크로 커밋은 분산 버전 제어에서 가장 좋아하는 기능입니다. 지점에서 작업이 다시 정리됩니다.
이 작업 스타일의 이점은 내가 작업중 인 변경 사항이 나쁜 생각이라는 것이 밝혀지면 쉽게 취소 할 수 것입니다. 실제로 변경 사항이 병합되지 않았기 때문에 취소 할 항목이 없습니다.
나는 게으르고 내가 개발하는 새로운 것을 위해 새로운 브랜치를 만들지 만들었습니다. 작업을 마치기 위해 예상했던 것보다 더 많은 시간이 필요할 때 항상 실수라는 것이 발견되었습니다. 이 과정에서 관련없는 또 다른 변화를해야 할 때 상황이 더욱 악화됩니다. 모든 작업이 자체적 인 분기 스타일을 따를 때 관련없는 변경을 자체 분기에서 수행하고 통합 한 다음 필요한 경우 다른 분기에서 변경 사항을 병합 할 수 있습니다.
저는 매일 Mercurial을 사용합니다. 여기를 참조 하십시오 . 또한 의욕, ShareSource 를 지원하는 몇 안되는 무료 호스팅 서비스 중 하나에서 도움을 줍니다 (크레딧 페이지에 있습니다). Xen 이 BitKeeper를 뜨린 이후로 저는 HG를 사용하고 있습니다.
개인 프로젝트의 경우 어떤 대가를 치르더라도 지점을 피하는 것이 좋습니다. 브랜치가 무엇인지에 대한 Mercurial의 아이디어는 예상했던 것과 일치하는 것입니다. Git과 같은 다른 시스템은 분기 (및 미친 과학자 아이디어)를 조금 더 쉽게 만듭니다. 하지만 저렴한 가격에 브랜치가 필요할 때만 Git을 사용합니다.
hg와 함께하는 나의 일상 :
(See where I left off)
# hg status
(See what I was doing with foo)
# hg diff -r tip src/foo/foo.c
(Finish one module, commit it)
# hg commit src/foo/foo.c
(Push changes)
# hg push
병합도 매우 간단 할뿐 아니라 관련 리포지토리에서 특정 개정판을 가져옵니다. 그러나 솔로 인 경우 해결을위한 병합이 제시되면 원격 저장소를 업데이트하지 않아 망가질 수 있습니다.
공개 한 지 1 년 만에 큰 인기를 얻은 솔로 취미 프로젝트를 몇 개 시작했는데, HG를 사용하게되어 기쁩니다. 구문은 Subversion에 가깝고 매우 낮고 이식성이 뛰어납니다.
물론입니다. 저는 Git과 SVN ..을 사용하지만 개인 프로젝트에는 사용하지 않습니다. 내 리포지토리 인덱스 (게시 된 링크)에 대한 메모, 나는 그 모양을 쉽게 수정하고 각 리포지토리에서 RSS를 가져오고 싶었 기 때문에 PHP에서 hgwebdir을 다시 작성했습니다.
요컨대, 개인적인 용도로 매우 친숙하다는 것을 알게 될 것입니다. 커밋, 태그 등은 간단합니다. 정말로 필요하지 않는 한 가지를 피하십시오.
이것은 Mercurial을 사용하여 웹 사이트를 관리 하는 방법을 설명하기 전에 얼마 전에 작성한 튜토리얼입니다. 키, hgrc 등을 설정할 때 흥미로울 수 있습니다.
이는 일반적으로 소프트웨어 프로젝트에서 작업하는 것과 동일합니다. 단순히 버전 제어가 있는지 여부는 논의의 여지가 없습니다.)
일반적으로 기능이 준비되면 커밋합니다. 백업이 있으므로 작업을 안전하게 저장하기 위해 매일 커밋 할 필요가 없습니다.
분기를 위해 : 내 솔로 프로젝트에서 주로 아이디어를 시도하는 데 사용합니다. 같은 문제에 대한 다른 해결책이있을 때. 이를 위해 Git의 숨김 명령도 좋아합니다.
그러나 여러 저장소가 있습니다. 내가 푸시하는 셸 액세스 권한이있는 호스팅이 있습니다. 그래서 어디서 일하고 어떤 워크 스테이션을 가지고 있든 상관없이 해당 저장소와 동기화 할 수 있습니다 (직장에서 : 코딩 할 시간이있을 때, 집 데스크톱에서, 부모 집에서 일할 때).
리포지토리가 상주 할 머신을 이미 백업하고 있기 때문에 여러 리포지토리를 원하는 이유를 모르겠습니다.
기능을 조사하고 메인 코드 브랜치에서 뒤섞이고 싶지 않다면 스스로 브랜치 할 수도 있습니다.
그러나 아마도 당신은 내가 이전에 제기 한 질문에서 무언가를 추출 할 것입니다 .
저는 이전에 CVS, Perforce, Subversion을 개인 버전 관리 시스템으로 사용했고 약 2 주 전부터 Mercurial에갔습니다 :-) 직장에서 우리는 MS Team System을 사용합니다 ...
저에게 가장 주목할만한 새로운 것은 다른 기계들 사이의 쉬운 전송입니다. 직장에서 나는 수은 저장소에 물건을 가지고 있습니다 (팀 시스템에 대한 슈퍼 클라이언트로 hg 사용). 나는 정기적으로 랩탑에서 모든 변경 사항을 밀고 / 끌어서 두 컴퓨터에서 전체 기록을 가지고 있습니다.
집에서는 랩톱에서 저장소를 밀거나 당깁니다.
결과적으로 어디서든 일할 수 있고 (무거운 컴퓨터를 사용하는 홈 오피스, 랩톱을 사용하는 이동 중 또는 직장에서) 변경 사항을 잃을 지 걱정하지 않아도됩니다. 좋아, 때로는 두 가지 변경 사항을 병합해야하지만 거의 아프지 않습니다 ... hg 꽤 멋지게 IMHO합니다.
또한 수은을 사용한 "설치 비용"은 매우 낮습니다. 튜토리얼을 읽고 설치하고 "hg init"라고 말하고 작업을 계속합니다. 더 이상 신성한 SVN 서버에 어떤 것이 있는지, 어디에 넣을지 결정할 필요가 없습니다. Mercurial의 "마찰"은 SVN보다 약간 낮습니다.
나는 이것이 기존 응용 프로그램을 유지하고 있는지 여부에 따라 생각 과 동시에 추가 기능 (또는 대형 버그를 수정).
이런 식으로 메인 브랜치의 버그를 수정하면서 자체 브랜치에 새 기능을 만들 수 있습니다.
내 응용 프로그램에서 정확히 수행하지만 로컬 버전의 CVS를 사용합니다. 또한 새 개발자가 팀에 추가되면 모든 준비가 완료된 것입니다.
이것은 백업과는 별개의 문제라는 데 동의합니다.
행운을 빕니다,
랜디 스테 그 바우어
SCM은 편집기의 일종의 "스마트"실행 취소 버퍼 확장입니다. 시간을 되돌릴 수 있고 문제를 해결했을 수도 있지만 리팩토링 되었기 때문에 삭제했지만 솔루션이 다시 필요할 것입니다. 커밋하거나 지난 이틀 동안 지속적으로 코드를 검토하고 이전 솔루션이 마음에 들지 않으면 코드를 변경합니다.
분기는 스트림에서 작동합니다. 한 방향으로 이동하기 시작했지만 더 많은 생각이 필요하고 그 동안 다른 작업을 수행하고 싶을 때 도움이 될 수 있습니다.
DVCS는 저장소를 단일 단위로 처리합니다. 필터를 사용하여 파일별로 커밋 할 수 있지만 전체 저장소에 대한 변경 사항을 저장합니다. 단일 파일 변경이 더 규칙적인 cvs (svn) 사용자를 혼동합니다.
(적어도 두 대 이상의 컴퓨터가있는 경우) 여러 클론이있는 또 다른 훌륭한 이유는 코드에 종속성을 도입했는지 쉽게 알 수 있기 때문입니다. (즉, 기본 워크 스테이션에있는 모든 개발 패키지가 없을 수있는 다른 시스템에서 코드가 실행됩니다.)
SCC를 구현할 수있는 다양한 방법을 설명하는 이 링크 를 읽고 대부분의 요구에 맞는 방법을 선택하는 것이 좋습니다.
Mercurial, Bazaar 및 Git과 같은 DVC는 한 군대가 확장 된 기능의 혜택을 누릴 수 있도록 많은 것을 저렴하게 제공했습니다.
작업 브랜치를 최신 상태로 유지하거나 메인 라인을 오프라인 상태로 유지하고 모든 델타를 의미있게 DVC에 동기화하는 데있어 규율을 유지한다면 "폐기"코드를 빠르게 실험 할 수 있습니다.
코드는 걱정없이 흐를 뿐이며 실제로 선호하는 솔루션을 선택하기 전에 여러 솔루션을 시도 할 수있는 정신적 자유를 제공 할 수 있습니다.
어떤 사람들은 크기에 관계없이 구현하는 각 기능 (특히 git)에 대해 분기를 만듭니다. 수은에서는이 개발 방식이 저렴하므로이 기능을 사용하지 않는 이유는 무엇입니까? 따라서 이것은 하루에 여러 번 더 큰 커밋이있는 작은 커밋을 의미 할 수 있습니다.
ㅏ. 이 접근 방식을 채택한 경우 해당 날짜에 수행 된 작업 과 WHS에 대한 백업이 발생 하는 시간 사이의 시간을 처리하기 위해 작업 일이 끝날 때 변경 사항을 오프 호스트 저장소로 푸시 할 수 있습니다 .
비. 내 WHS에 CopSSH 를 설치 했으며 SSH / SFTP / SCP 기능을 Windows 상자에 ~ 5MB로 훌륭하게 제공합니다. 이전에는 Virtual Server 2005에서 Ubuntu Linux를 실행하여 다른 서비스 중에서 유사한 기능을 제공했습니다. 수은을 ssh를 통해 WHS 상자에 넣을 수 있습니다.
나는 항상 Git 또는 Mercurial을 혼자 사용합니다.
재사용 가능한 일부 구성 요소를 다른 프로젝트에서 사용할 수 있도록하려면 저장소를 분리합니다. 커밋 할 때 자동으로 푸시하도록 구성했습니다 (Tortoise HG 플러그인을 사용했습니다). 때로는 푸시하는 것을 잊었 기 때문에 지리적으로 이동할 때 해당 코드가 필요합니다.
그래서 이것이 제 팁입니다.
참고 URL : https://stackoverflow.com/questions/277208/how-should-i-use-mercurial-as-a-lone-developer
'ProgramingTip' 카테고리의 다른 글
| Jersey Client를 사용하여 자체 서명 된 SSL 인증서 무시 (0) | 2020.11.29 |
|---|---|
| PHP var_dump () 값이 값당 한 줄을 표시하도록 만들기 (0) | 2020.11.29 |
| 자바 프로그래머로서 무엇을 찾아야합니까? (0) | 2020.11.28 |
| 주석을 지향하는 Java Aspect 지향 프로그래밍 (0) | 2020.11.28 |
| 모바일 앱용 NoSQL? (0) | 2020.11.28 |