발생일: 2013.06.03 문제: 그 동안은 개인 프로젝트에서만 GitHub을 사용했는데,이번에 회사를 옮기면서 회사 프로젝트에서도 GitHub을 사용할 기회가 생겼다.^^ GitHub을 여럿이서 적극적으로 사용해보는 건 처음이라, 팀원들끼리 여러 방법으로 실험해봤다. 다른 팀원들은 맥용 GUI 도구인 SourceTree 앱을 주로 사용하는데,난 아직까지 커맨드라인이 익숙하고 편하다. 이번에 자세히 살펴보면서, 요긴하게 사용할 수 있는 몇 가지 명령어를 메모해뒀다. 해결책: 리모트를 포함한 브랜치 정보 보기$ git branch -va 리모트 정보가 업데이트 필요할 때$ git remote update 로그 보기$ git log 그래프 형태로 보기$ git log --graph 한 줄로 보기$ git ..
발생일: 2013.06.03 문제: 난 주로 커맨드라인에서 Git을 사용하고 있다.그러고보니, git 명령어도 자동완성이 되게 사용할 수 있을 것 같은데~어떻게 설정하면 될까? 해결책: `git bash completion osx` 키워드로 구글링하면 여러 방법이 나온다. homebrew나 macports 같은 패키지 도구를 이용해 다운로드 받는 방법도 있지만,난 Git 소스 리파지터리에서 bash_completion 쉘스크립트를 다운받아 실행하는 방법으로 해결했다. 1. Git 소스를 다운로드 받는다. $ git clone git://git.kernel.org/pub/scm/git/git.git 2. 다운로드 받은 리파지터리에서 `contrib/completion/git-completion.bash` ..
발생일: 2013.03.31 문제: 며칠 전에 Pro Git 책을 다시 읽었다.git 은 평소에도 늘 사용하고 있고, 1년 전에도 한 번 읽었던 책인데,처음 읽은 것처럼 새로운 내용이 많더라. ㅎㅎ 예전에 git 브랜치를 효과적으로 나누고 관리하는 방법에 대해,홍과 Y형에게서 공유를 받은 적이 있다. Vincent Driessen 라는 개발자가 공유한 브랜칭 방식인데,브래칭 전략을 손쉽게 쓸 수 있게 git flow 라는 도구도 만들어놨다. 하지만 그 개념이 좀 복잡하게 느껴지기도 했고,git은 개인 프로젝트에서만 사용하고 브랜치도 개발용만 따로 땄던 터라,"뭐 그냥 그런 게 있군" 하고 넘어갔더랬다. 그러다 이번에 책을 다시 보고,git flow 를 다시 살펴보니, 오~ 정말 깔끔하고 훌륭한 브랜칭 전..
발생일: 2012.10.29 문제: 최근, 팀에 새로운 분들이 많아지면서, 팀 내 코드 리뷰 미팅도 부쩍 많아졌다. 우리 팀에서는 주로 아래와 같은 방법으로 코드 리뷰를 진행한다. 1. 리뷰받을 사람이 미팅을 요청하고, 시간이 되는 사람들이 참석한다. 2. 회의실에 모여서, 리뷰받는 사람이 작성한 코드에 대해 설명한다. 3. 설명 중간 중간 참가한 사람들이 해당 코드에 대해 질문하고 의견을 준다. 이렇게 하는 방식은 "여러 사람들의 의견을 들어볼 수 있다"는 게 가장 큰 장점인 것 같다. 하지만, 리뷰에 참여한 사람이 많다보니, - 리뷰가 코드에 대한 논쟁으로 진행되거나, - 컨벤션 지적질이 되거나, - 아무 말도 안하는 사람도 생기게 되고, - "잠깐 잠깐 저기요. 아뇨. 아래아래. 아 거기." 이런 ..
발생일: 2012.01.16 문제: 담당하고 있는 서비스에서는 버전 관리 도구로 SVN을 사용하고 있다. 배포는 서버 개발팀에서 담당하고 있는데, 매 배포에 대한 버전 관리는 어떻게 관리하는 지 궁금해서 물어봤더니 각 릴리스에 대한 버전을 브랜치로 따서 관리한다고 한다. 예를 들어, v.1.0을 배포하고자 할 경우, Release Branch의 약어를 써서 RB-1.0 과 같은 이름의 브랜치를 따고, 해당 브랜치를 배포하는 식이다. 요새 Git으로 관리하고 있는 개인 프로젝트에서도 브랜치로 배포 버전을 따면 되겠구나~하고 생각하고 있었는데, 이것저것 알아보다 보니 실제로 브랜치보다는 태그(Tag)를 더 많이 사용하는 모양이다. 태그는 뭐고, Git에선 어떻게 사용하는 걸까? 해결책: 버전 관리 시스템에서..
발생일: 2012.01.15 문제: git에서 커밋할 때엔 항상 git add . 명령어로 커밋할 대상을 골라놓은 후, git commit -m [message] 명령으로 커밋했다. git add 가 정확히 어떤 것인지 모르고 습관적으로 실행했었는데, 이번에 책을 읽다가 알게된 내용을 메모해둔다. 해결책: Git 프로젝트의 세 가지 단계 가장 먼저 Git 프로젝트의 세 가지 단계에 대해 이해해야 한다. Git 프로젝트에는 Git Directory, Working Directory, Stating Area 세 가지 단계가 있다. Git Directory는 Git이 프로젝트의 모든 정보를 저장하는 곳이다. Git의 핵심이라 할 수 있고, Git을 새로 구축하거나 다른 저장소에서 Clone할 때 Git Dir..
발생일: 2011.12.01 문제: git 으로 관리하고 있는 소스 폴더가 있는데, 사용하지 않는 파일을 git bash가 아닌 윈도우 폴더에서 삭제했다. 파일 삭제 후 커밋하고 github으로 푸시했는데, 이상하게 폴더에서 삭제한 파일은 github에 반영이 되어 있지 않더라. 이상하다고 생각하고, 매뉴얼을 찾아보다가 git rm 이란 명령어가 있는 걸 발견했다. rm 도 add 랑 같은 개념이라고 생각하고 가볍게 git rm -r . 명령어를 날렸는데, 폴더 내 모든 파일이 삭제되더라. 오... 갓. 해결책: git reset --hard HEAD 역시 스택오버플로우. ㅎㅎ http://stackoverflow.com/questions/2125710/how-to-revert-a-git-rm-r