독립 개발자를위한 버전 관리?


60

독립 개발자 인 경우 버전 제어를 사용하는 것이 가치가 있다고 생각하십니까? 그렇다면 왜 그럴까요? 리포지토리를 자신의 컴퓨터 나 백업으로 사용할 수있는 다른 곳에 보관합니까?


54
나는 약사가 다음과 같은 질문을하고 싶다 : "약을 체계적으로 보관해야합니까? 아니면 서랍에 모두 던져야합니까? 노력할만한 가치가 있습니까?"
Erik

23
이 멋진 소프트웨어를 일주일 동안 열심히 일한다고 상상해보십시오. 그런 다음 삭제하십시오. 기분이 어떻습니까? 단순한 저장 공간이 아닙니다. 지난 주에 효과가 있었던 것이 깨졌을 때, 무엇이 바뀌 었는지보고, 보통 내가 깬 것을 볼 수 있습니다. 여전히 backup001 및 backup_backup001 폴더가 소스와 혼합 된 '전문적인'개발자를 봅니다. 아직 어릴 때 좋은 습관을들이십시오.
Erik

@Erik Yuck, 백업 폴더가 불쾌하게 들립니다. 나는 종종 커밋에 능숙하지는 않지만 프로젝트에 소스 컨트롤을 사용합니다.
vedosity

답변:


61

분산 소스 제어 (Mercurial, Git 또는 Bazaar 등)를 사용하는 경우 SVN / CVS에 비해 장점이있어 인디 인 경우 사용하기 쉽고 유용하며 강력합니다.

  1. 로컬로 커밋 : 프로젝트 디렉토리는 전체 히스토리가있는 리포지토리입니다. 따라서 서버가 없어도 저장소에 직접 커밋하고 동일한 컴퓨터에 여러 개의 저장소를 가질 수 있습니다. 일을 계속하기 위해 때때로 열어 놓은 랩톱을 사용하십니까? 큰! 서버를 설정할 필요가 없으며 나중에 서버를 설정해야 할 경우 쉽고 간단하며 리포지토리간에 변경 사항을 "밀어 내기"및 "풀링"하기 만하면됩니다.
  2. 실험을 쉽게하기 위해 만들어졌습니다 . 종종 코드를 오염시키지 않고 기능에 대한 아이디어가 필요합니다. SVN 및 CVS를 사용하면 이미 브랜칭 시스템을 사용하고 원하는만큼 기능이 좋지 않은 경우 브랜치를 버릴 수 있습니다. 그러나 기능을 트렁크 버전과 병합하려는 경우 놀라움을 해결하기가 어렵습니다. Git, Mercurial 및 Bazaar는 (적어도) 병합 및 분기를 정말 쉽게 만듭니다. 원하는 경우 리포지토리를 복제하고, 일정 시간 동안 작업하고, 계속 커밋하고 종료하거나 기본 리포지토리에서 변경 사항을 푸시 할 수도 있습니다.
  3. 조직의 유연성 : 이전에 지적했듯이 필요에 따라 구성 할 수있는 리포지토리가 있으므로 혼자서 시작하기 쉽고 조직을 변경하여 다른 사람들과 함께 일할 수 있습니다. 조직이 부과되지 않으므로 조직을 설정하고 구성하기 만하면됩니다. 나는 종종 내 컴퓨터 (노트북 / 데스크탑 / 서버) 사이에서 변경 사항을 푸시 / 풀하고 여전히 내 개발자에 혼자 있습니다. Mercurial을 사용하여 작업 내용을 복제하는 데 도움이되지만 랩톱 외부에서 생각한 기능을 작업 한 다음 데스크톱의 다른 기능을 계속 수행 한 다음 데스크톱 또는 서버에서 랩톱 변경 사항을 푸시하고 전체 데스크톱을 병합합니다. 랩톱에 넣고 서버에 백업 및 향후 팀워크 저장소로 넣습니다.
  4. 백업 설정에 도움 이됩니다. 중앙 저장소 (공용 인 경우 GitHub 또는 BitBucket의 개인 저장소)를 설정하면 컴퓨터가 부팅 될 때마다 실행될 스크립트를 쉽게 작성할 수 있습니다. 정기적으로 작업을 자동으로 백업 할 수 있습니다. 그것은 내가 지금하고있는 일입니다. 내 일을 잃기 쉽지 않을 것이라고 확신합니다.

실제로 현재 프로젝트에 제어 소스 도구를 사용하지 않을 이유가 없습니다. 이전보다 더 강력하고 유연하기 때문에 필요에 따라 확장 할 수 있습니다.



8
또는 bitbucket.org을 당신은 의욕을 사용하는 경우.
Terence Ponce

7
dropbox에 로컬 파일 시스템 저장소가있는 Mercurial은 단일 개발자에게 효과적입니다.
Pieter Breed

1
@Guillaume : 단일 개발자가 DVCS의 "분산 된"측면을 사용할 수 있습니다. 나는한다. 예를 들어, 컴퓨터 A에서 작업하고 USB 키로 작업을 푸시 한 다음 컴퓨터 B에서이 USB 키를 가져옵니다.
barjak

1
@Guillaume "Distributed"는 조직적인 측면이 아니라 기술적 측면입니다. 커밋 된 코드의 유효성 검사 만 허용 된 통합자가있는 중앙 집중식 소스 시스템을 사용할 수 있습니다. 도구의 중앙 집중식 특성으로 인해 가능하지만 설정하기가 어렵습니다. 그러나 그것은 여전히 ​​직교적인 문제입니다.
Klaim

34

우리 모두가 알고 있듯이 소스 코드 제어는 독립적 인 개발자에게는 전혀 쓸모가 없습니다.

  • 독립 개발자는 결코 실수하지 않습니다
  • 독립적 인 개발자는 해결되지 않는 개정판을 사용하지 않습니다.
  • 독립 개발자는 둘 이상의 버전을 가지지 않으므로 브랜치를 사용하지 않습니다.
  • 독립 개발자는 어제 또는 지난주에 변경된 사항에 신경 쓰지 않습니다.
  • 독립 개발자는 절대 백업을 필요로하지 않습니다

"종속 개발자"라고 부릅니다. Mercurial 저장소는 데스크탑, 랩톱, USB 백업 드라이브 및 bitbucket.org간에 쉽게 복제됩니다. 나는 의존적으로 성장했고, 나는 그것을 좋아한다!


6
이 답변은 냉소적인가?

4
@ 커트 넬 : 매우!
Steven A. Lowe

1
Kewlio, 방금 확인했습니다.

21

왜 안돼?

저는 솔로 개발자이며 개인 프로젝트에 BitBucket과 Mercurial을 사용합니다. 코드를 되돌리고 포크하는 기능은 너무 지나치지 않습니다.


8
BitBucket +1-무료로 무제한 개인 저장소를 제공합니다.
Jon Sagara

2
무료 개인 저장소는 GitHub에서 BitBucket을 사용하는 이유입니다.
Terence Ponce

4
무료 개인 레포 ?? 나를 git에서 hg로 변환했을 수도 있습니다.
Gauthier

@Gauthier, Yep, BitBucket에는 무료 개인 저장소가 있습니다. 그들은 무제한인지 확실하지 않습니다.
Terence Ponce

1
비트 버킷과 함께 git을 계속 사용할 수 있습니다. 실제로 ssh 키를 포함하여 github에서 직접 가져옵니다. 그냥 이동을했지만 여전히 자식을 사용 (I 더 좋아!)
다니엘 Casserly

1

개인적으로 가치가 있습니다. 내 프로젝트는 모두 git 리포지토리에 체크인되어 있습니다 (하드웨어 오류가 발생하면 여러 컴퓨터에 보관합니다). 가장 유용한 기능은 브랜칭 (내 코드베이스의 절반을 엉망으로 만들고 영구적으로 아무것도 날릴 염려가없는 실험을 실행할 수 있음) 및 되돌림 (기본적으로 스테로이드에 대한 실행 취소입니다. 일반적인 실행 취소 범위를 벗어난 실수).


1

예. 매우 유용합니다. 내 친구 Matt Gallagher 는 며칠 전이 주제에 관한 이 훌륭한 기사 를 그의 "Cocoa With Love"iOS / MacOS 개발 블로그에 게시했습니다.

이 기사는 Mac & Git 중심이지만 기본 사항을 다룹니다.

다음 StackExchange 질문 (및 답변)에 관심이있을 수도 있습니다.


1

가치?? 곰팡내 나게 하다! 소스 제어를 사용하지 않으면 소스를 제어하지 않으므로 나쁜 것입니다. 되돌릴 수 없다고, 변경 사항을 추적 할 수는 없습니다. 방금 입력 한 더미 버그를 찾기 위해 몇 시간을 소비합니다. 일부 백업 서버에 보관하는 것이 좋지만 컴퓨터를 사용하고 적절한 백업 방법을 사용할 수도 있습니다.


2
실제로 소스 제어를 사용하지만 과도한 엔지니어링과 과잉 작업을 채택하는 경향이 있습니다. 나는 직장에서 이것으로 잘 알려져 있습니다. 다시 말하지만, 저를 포함하여 일하는 프로그래머는 다른 곳에서 프로그래머로 일한 적이 없으며 우리 대부분은 여전히 ​​고등학교에 있다고 생각합니다.
vedosity

1

소스 컨트롤을 사용하십시오. 그런 다음 빌드 서버를 설정하고 빌드 및 테스트 프로세스를 자동화하십시오. 중앙 저장소의 소스 커밋에서 빌드를 트리거합니다. 나는 이런 식으로 3 년 동안 혼자서 일해 왔으며 훌륭합니다.


0

예.

심지어 단일 개발자조차도 과거의 일부 개정판에서 코드 상태를 확인해야합니다. 그리고 중요한 모든 것을 백업하는 것은 항상 좋은 생각이며 모든 사람들에게 적용됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.