Whiteship's Note


[봄싹]기트 도입 실패 사례

모하니?/Coding : 2009.08.06 18:59


봄싹 스터디에서 Git라는 분산 VCS를 사용해 보기로 결정하고, 사전 조사를 거친다음, 간단한 사용법을 공유하고, 개발을 시작했다. 그러나 개발은 더뎠다. 얼마전 더디다 못해 거의 진척이 없다시피 하는 모습을 보고 Git에서 SVN으로 버전 관리 시스템을 바꿨다. 그리고 프로젝트의 데드라인도 설정했다. 그러자... 이게 왠일인가..


불과 2주 만에 총 9명의 개발자가 온/오프라인에서 뜨겁게 개발에 참여하고 있다. 현재 이 모습은 내가 봄싹 구글 그룹스를 처음 만들 때 상상하던 모습이다. 이대로만 간다면, 8월 29일 데드라인 안에 사이트 1차 개발을 마칠 수 있을 것 같다.

바뀐 요인은 딱 두 가지. 1. 데드라인 설정. 2. 개발자에게 보다 편리한 개발 환경으로 전환. 어쩌면 2번은 1번으로 인해 불가피 했을지도 모르겠다. 처음에는 느긋하게 기트에 적응해가자면서 개발을 하자고 생각했었다. 하지만 그것은 오산이었다.

기트를 사용하고 있지만, 기트를 사용하는 시나리오는 예전 SVN을 사용하던 때와 별반 다르지 않았다. 수시로 branching/merging을 하지 않을 꺼라면 굳이 Git를 사용할 필요가 없다는 것을 몸소 체험했으며, 중간 관리자를 거쳐야만 하는 대규모 개발도 아니기 때문에 한방에 서버로 바로 커밋/업데이트하는 SVN이 그립기도 했다. 또한 이클립스 툴 지원이 아직도 미약했다. 마지막으로 별도의 기트 서버를 운영하지 않고 GitHub를 이용했는데, 나중에는 사용자가 많아져서 계정 관리하는 것이 어려웠다. 이 부분은 아마도 봄싹에서 GitHub를 잘못이용한 것이 아닌가 하는 생각이 든다. 애초에 내 계정에 다른 개발자들의 공개키를 등록하는것이 아니라, 프로젝트에서 별도의 브랜치를 따다가 자기 계정에서 관리하는 형태로 프로젝트를 진행했어야 하는 듯 하다.


그래서 모두에게 익숙한 SVN으로 넘어왔다. 결국은 기트 도입이 실패했지만, 프로젝트는 실패하지 않았다. 어쩌면 그로인해 프로젝트 성공의 길로 한 걸음 더 다가간 것 같이 느껴진다. 비록 이번에는 기트 도입이 실패했지만, 다음에 적절한 상황이 오면 다시 시도해 볼 생각이다. 다음에는 기트허브에서 새로운 방식으로 개발을 진행하던지, 별도의 기트 서버 환경을 구축한 뒤에 해볼 생각이다. 그때가 되면 이클립스 툴도 조금은 진전이 있겠지...??

ps: 예상외로 메이븐 도입에 대해서는 다들 잘 수긍하는 편이었다. 처음부터 메이븐 리파지토리, 플러긴, 페이스, 골 등의 개념 설명을 한 적이 없고, 필요한 명령어만 몇개 알려드리고, pom.xml에 의존성 추가하는 것만 알려드렸다. 기트가 워낙 충격적이어서 그랬나...? 아무튼 메이븐은 기트에 비하면 도입이 쉬운편이었다. 봄싹에선 말이다.



top


기트(Git)와 SVN으로 동시에 버전 관리하기

Good Tools : 2009.04.27 14:14


기트에서는 SVN 정보를 버전관리에서 제외하고 SVN에서는 기트 정보를 버전관리에서 제외해줘야 합니다. 그래야 깔끔하겠죠. 기트로 버전 관리는 하는데 괜히 모든 폴더마다 .svn 폴더가 생기고 그 안에 또 여러 폴더와 파일들까지 딸려 온다면... 쫌~ 그르치요~!

기트에서 SVN 정보를 버전관리 대상에서 제외하는 방법은 간단합니다. 프로젝트 루트에 .gitignore 파일을 만들고 그 안에 .svn 과 .svn/* 을 추가해주시면 됩니다. 두 번째 것 만 등록해도 될런지 모르겠습니다.


반대로 SVN에서는 프로젝트 루트에 있는 .git 폴더와 .gitignore 파일만 ignore 시켜주면 됩니다. 이렇게 하면 이제부터 이클립스에서는 subversive 플러긴을 이용해서 SVN에 커밋&업데이트를 할 수 있고, 콘솔로는 기트를 이용하여 로컬에 commit을 하고 원격에 push, pull 하면서 두 개의 버전관리 시스템을 사용할 수 있겠습니다.

둘 중 하나는 뷰 전용으로 하고, 다른 것 하나를 주요 버전 관리 시스템으로 사용하면 좋을 것 같습니다. 예를 들어, SVN을 뷰 전용으로 사용하고 기트를 사용하여 실제 개발을 하면서 중간 중간 push할 때 마다 SVN에 같이 커밋해주는 식으로 사용하면 될 것 같습니다.

'Good Tools' 카테고리의 다른 글

오늘 하루 타일즈(Tiles)에 낚였나보다~  (2) 2009.05.01
스프링 MVC에서 타일즈 2 사용하기  (2) 2009.05.01
Tiles와 SiteMesh 차이  (0) 2009.05.01
Tiles VS SiteMesh  (2) 2009.05.01
Prototype VS JQuery 트랜드 비교  (2) 2009.04.28
기트(Git)와 SVN으로 동시에 버전 관리하기  (4) 2009.04.27
Github 맘에 드네~  (0) 2009.04.25
Github에 pull, push하기  (2) 2009.04.14
기트(git) config  (0) 2009.04.09
기트(git) 주요 명령어  (2) 2009.04.07
기트(Git) 주요 개념  (8) 2009.03.30
top


Github에 pull, push하기

Good Tools : 2009.04.14 11:37


간단하지 않더군요. public 저장소라길래 아무나 소스 코드 받고 아무나 소스 코드 수정해서 올릴 수 있나보다 했는데.. 그게 아니더군요. 아무나 소스 코드를 받아 갈 수는 있습니다. 하지만 아무나 소스 코드를 수정할 수는 없더군요. 즉.. pull은 자유롭지만 push는 그렇지 않았습니다. push를 하려면 공개키, 비공개키를 만든다음, 공개키를 public 저장소에 등록해 두어야 push할 수 있습니다.

0. pull 하기

git pull URI

이런 형태로 하면 프로젝트를 가져옵니다. 따라서 workspace에서 실행하는게 좋겠죠.

1. 공개키, 비공개키 만들기

http://github.com/guides/providing-your-ssh-key

여기를 참조하셔서 리눅스, 맥, 윈도우에서 키를 만듭니다.
주의할 것이 있는데, 키를 만들 때 사용한 passPhrase..
키워드 같은 것을 기억해 두세요. 기억력이 약하시면 어딘가에 저장해 두세요.

2. 공개키를 public 저장소에 등록하기

사용자 삽입 이미지

이런 식으로 공개키를 등록해 줍니다. 물론 저 화면에는 아무나 들어갈 수 없고 public 저장소 주인장만 들어갈 수 있죠. 따라서 팀원들은 공개키를 만든 다음에 주인장에게 공개키를 전달해야 합니다.

3. push 하기

git push git@github.com:사용자/저장소.git

이런 형태로 쓰면 됩니다. 그러면 중간에 passphrase를 입력하라는 콘솔이 뜹니다. 그럼 이제 키를 만들 때 입력한 passphrase를 입력하시면 끝~~

다음에는 branch, merge, conflic 해결등을 다뤄볼까 합니다.

'Good Tools' 카테고리의 다른 글

Tiles와 SiteMesh 차이  (0) 2009.05.01
Tiles VS SiteMesh  (2) 2009.05.01
Prototype VS JQuery 트랜드 비교  (2) 2009.04.28
기트(Git)와 SVN으로 동시에 버전 관리하기  (4) 2009.04.27
Github 맘에 드네~  (0) 2009.04.25
Github에 pull, push하기  (2) 2009.04.14
기트(git) config  (0) 2009.04.09
기트(git) 주요 명령어  (2) 2009.04.07
기트(Git) 주요 개념  (8) 2009.03.30
JGit 설치  (0) 2009.03.26
아이폰 애플리케이션 iDie  (0) 2009.03.03
top

TAG Git, GitHub, Pull, push

기트(Git) 주요 개념

Good Tools : 2009.03.30 16:16


참조: http://git.or.cz/course/svn.html

저장소(Repository): 서브버전에서 각각의 프로젝트는 체크아웃하고 커밋하는 중앙에 위치한 단일 저장소에 위치한다. Git는 다르게 동작한다. 각각의 프로젝트 트리(working copy라고 부른다) 복사본을 각자의 저장소에 가지고 있는다. 따라서 로컬과 원격 브랜치를 가질 수 있다. 또한 워킹 카피에 붙어있지 않은 베어 저장소(Bare repository)를 가질 수 있는데, 이 것은 특히 저장소를 공개하고 싶을 때 유용하다.

URL: 서브버전에서 URL은 저장소 위치 식별자와 저장소 내부 경로를 나타낸다. 따라서 저장소의 레이아웃과 그 의미를 구조화 한다. 보통 trunk/, branches/, tags/ 디렉터리를 가지고 있을 것이다. 기트에서 URL은 단순 저장소 위치다. 브랜치와 태그는 항상 내포하고 있다. 브랜치중 하나를 기본으로 사용하고 그 이름이 보통 master다.

리비전(Revision): 서브버전은 리지번을 증가만 하는 정수 id로 식별한다. 대규모 프로젝트에서는 금방 수 백, 수 천이 되는 경향이 있다. Git 같은 분산 시스템에서는 실용적이지 않다. Git는 SHA1 id로 리비전을 식별한다. 16 진수의 기다란 160 비트 숫자다. 처음엔 좀 당황스럽지만 실제로는 그리 방해가 되지 않는다. 최신 리비전을 HEAD로 참조할 수 있고, 그 부모를 HEAD^ 로 참조하고 부모의 부모는 HEAF^^ = HEAD^2 이런식으로 참조할 수 있다. 또한 리비전의 앞 부분 몇 개만으로 참조할 수 있다. 그것으로 식별할 수 있다면 기트가 나머지를 추측할 것이다.

커밋(commit): 각각의 커밋은 author와 committer가 있다. 누가 언제 코드를 변경했고 누가 그것을 커밋했는지 알려주는 정보다.(Git는 메일로 주는 패치를 잘 적용할 수 있도록 설계 했는데, 이런 경우 author와 committer가 다를 수 있다.) git config -I로 이름과 이메일을 확인할 수 있다. 그리고 다음 명령어로 그 정보를 설정할 수 있다.

git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com

명령어: git command 형태인데, git-command 형태로 사용할 수도 있다.

색상: 다음과 같이 설정하면 컬러풀한 결과를 볼 수 있다. 기본값으로 색상을 사용하지 않는다.

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

비주얼: gitk를 사용해서 저장소를 살펴보면 편리할 것이다. 맥용 gitk 대체 애플리케이션

'Good Tools' 카테고리의 다른 글

기트(Git)와 SVN으로 동시에 버전 관리하기  (4) 2009.04.27
Github 맘에 드네~  (0) 2009.04.25
Github에 pull, push하기  (2) 2009.04.14
기트(git) config  (0) 2009.04.09
기트(git) 주요 명령어  (2) 2009.04.07
기트(Git) 주요 개념  (8) 2009.03.30
JGit 설치  (0) 2009.03.26
아이폰 애플리케이션 iDie  (0) 2009.03.03
구글 토크 사전  (4) 2009.01.05
Word Cloud 만들어보기  (0) 2008.12.08
i구글의 날씨 위젯 좀 짱인듯..  (0) 2008.11.28
top

TAG Git

JGit 설치

Good Tools : 2009.03.26 15:41


이클립스 업데이트 사이트: http://www.jgit.org/update-site
위 업데이트 사이트를 이용해서 설치하면 됩니다.

그런 다음 Git로 버전 관리할 프로젝트에서 Team -> Share Project -> Git를 선택합니다. 그럼 이제 Team 메뉴에서 Git 명령어 몇 개를 사용할 수 있습니다.

사용자 삽입 이미지
사용자 삽입 이미지

아직은... 툴 지원이 Subversion에 비해 미약한 듯 합니다. 특히 Git에서 자주 사용할 것 같은 명령어인 Add, Commit, Pull, Push에 대한 단축키가 지정되어 있지 않다는 것이 좀 걸립니다. 물론 수동으로 단축키를 등록하고 사용하는 방법도 있지만... 조금 귀찮죠.

새로 추가한 파일은 관리 대상이 아니라는 표시가 나오고 관리 중인 코드를 변경하고 아직 commit 하지 않았을 경우 not updated라고 표시해줍니다. 이 상태에서 commit을 하면 not updated인 코드만 commit하고 새로 추가한 파일은 commit하지 않습니다.

오른쪽 조그만 빨간색은 JUnit Max인데 저장하는 순간 바로 테스트를 하고 그 결과를 알려주기 때문에 굉장히 유용한 툴인것 같습니다. 손수 테스트를 돌리지 않아도 되기 때문에 코딩 흐름을 빠르게 이어 나갈 수 있습니다.

'Good Tools' 카테고리의 다른 글

Github 맘에 드네~  (0) 2009.04.25
Github에 pull, push하기  (2) 2009.04.14
기트(git) config  (0) 2009.04.09
기트(git) 주요 명령어  (2) 2009.04.07
기트(Git) 주요 개념  (8) 2009.03.30
JGit 설치  (0) 2009.03.26
아이폰 애플리케이션 iDie  (0) 2009.03.03
구글 토크 사전  (4) 2009.01.05
Word Cloud 만들어보기  (0) 2008.12.08
i구글의 날씨 위젯 좀 짱인듯..  (0) 2008.11.28
IntelliJ도 좋아보이는데.. 상용인게 안타깝네요  (4) 2008.11.10
top


Git - 분산 버전 관리 시스템(Distributed VCS)

Good Tools : 2008.08.10 20:35


참조
http://www.infoq.com/articles/dvcs-guide
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
http://bazaar-vcs.org/Workflows
http://github.com/

먼저, 분산 이라는 표현이 좀 애매해서 이해하는데 어려울 수 있는데, "독립적인" 또는 "peer-to-peer"라는 표현이 더 좋겠다는 생각에 동의합니다.(두번째 링크 참조)

사용자 삽입 이미지
첫번째 링크에서 퍼온 그림.

위 그림을 보고 대충 짐작을 할 수 있습니다. 기존의 방식은 왼쪽처럼 한 곳에 중앙 리파를 두고 거기에 소스코드를 커밋or체크아웃/업데이트 하는 방식이었데, 분산 VCS에서는 각자가 자신만의 리파를 두고 그곳에 코드를 변경합니다. 외부로 접속하지 않으니깐 빠르겠죠. 그리고 서로 각자가 변경한 코드들을 상대방에서 push 해서 상대반 저장소의 코드를 업데이트 하거나, pull 해서 끌어올 수 있습니다. 마치 각자가 브랜치를 가지고 작업하는 것과 동일합니다. 그러다가 서로 충돌나는 부분이 있으면 merge를 하면 되는데, CVS나 SVN에서의 merge랑은 차원이 다르게 간편하고 유용하다고 합니다.

리누즈 토발즈는 SVN을 뭘하는 건지 모르겠는 프로젝트(pointless project)라고 비아냥 거렸고, CVS를 좋아하는 사람들은 정신병원에 가야한다는 농담을 했습니다.(두번째 링크에 리누즈 토발즈의 동영상 중에 직접 언급을 하며, 첫 번째 링크에는 아래처럼 요약해 두었습니다.)
Linus Torvald: "Subversion has been the most pointless project ever started". "If you like using CVS, you should be in some kind of mental institution or somewhere else".
Git 같은 분산 VCS를 사용해서도, 중앙 리파를 쓰는 CVS나 SVN을 쓰듯이 워크 플로우를 잡을 수 있습니다. 하지만, CVS나 SVN으로는 구성할 수 없는 워크 플로우를 Git를 사용해서는 구성할 수 있습니다. 예를 들어, 세번째 링크에 있는 Decentralized with human gatekeeper 모델은.. 아래와 같습니다.
사용자 삽입 이미지
주 코드에 변경을 가하기 전에 누군가 코드를 검사한 다음 그 걸 반영하는 워크 플로웁니다. 개발자가 많고 각각의 실력 편차가 심한 상황에서 코드 품질을 관리하려면, 선임 개발자 몇명을 두고, 저런 워크 플로우로 개발하는 것이 좋겠죠. 그러나 SVN으로.. 저런 걸 어떻게 할까요? SVN에는 저런 워크 플로우를 지원하기 위한 어떤 것도 없습니다. Git같은 분산 VCM으로는 가능합니다. 하는 방법도 위에 써져있죠. ㅋ

pull/push/update/merge에 대한 용어 설명은 두 번째 링크에 있습니다.

재밌는 툴인거 같습니다. 저장소를 설치하기 귀찮다면 100메가까지 무료로 제공해주는 웹 리파를 사용할 수 있겠습니다. 네 번째 링크에 있습니다.

위와 같은 신기한 툴을 알려주신 사부님께 땡큐입니다. SVN으로 평생 commit/update만 하면서 살뻔했는데, 이젠 branch나 merge같이 좀 더 SCM 스러운 툴을 써볼 수 있게 됐네요.
top

TAG Git, SCM, VCS

Git - Fast Version Control

Good Tools : 2008.08.07 18:05


http://git.or.cz/

CVS, SVN만 알고 있었는데, 새로운게 있었네요. 엄청나게 빠르다는게 장점 중 하나인 것 같습니다. 얼마나 빠르길래;;
top

TAG Git, SCM