[Git Tip] Git에 대한 궁금증들

Technical/Development

[Git Tip] Git에 대한 궁금증들

Barracuda 2015. 7. 24. 14:42

Git 을 다루는 엔지니어들이 점점 늘고 있다. 한글 입력상태에서 자판으로 git을 치면 '햣' 이 된다, 햣~! 너도 나도 써야한다라고 하니, 이게 마치 무슨 대세가 된 건 아닌가 착각도 하게 되는데, 막상 써보려니 손에 익고 간편한 cvs, svn 과는 비슷하면서도 뭔가 좀 다르고 어렵기도 하다.

근데, 간편안내서 같은 곳을 보면 "어렵지 않아요 ;)" 하면서 사람을 막 꼬드긴다(가서 보면 더 너무 쉽게 써놔서 더 아리송하다). 그게 대체 뭐길래...하면서 약도 좀 오르고 궁금하기도 하다. 이제, 하나 하나 따져가면서 왜 그런가 고민하고 정리해 두는 버릇이 있는 필자가 git을 한 번 다루어 보려 한다.

Git을 써야 하는 이유

결론부터 간단히 말하자면, Git 은 약간의 개념공부와 실습이 필요한 Tool 이다. cvs, svn 과는 달리 Git은 Distributed+VCS(버전관리도구) 이고 cvs가 하지 못하는 일을 가능하게 하기 때문이다. Linux의 주인공 리누즈 토발츠는 자신이 만든 Git을 소개하면서 cvs를 'devil'(악마...라기 보다는 죄악에 가깝다고 본다) 라고 까지 한다(아래 유튜브 영상 참고). cvs나 svn을 쓰면서 branch-merge하기 전에 풀백업을 받아 두는 엔지니어의 심정이라면 Git을 써야만 하지 않을까?

왜 Git을 써야 하는지에 대해 인터넷에 수많은 문서들이 올라오고 있지만, 이 페이지를 보고 좀 더 명료해 지리라 생각된다.

http://pismute.github.io/whygitisbetter/

아마도, 이 정도 개념만 잡고 개발팀에 투입 돼도 "이 친구 쫌 하는데!" 라는 시선을 받아 볼 수 있을런지도 모르겠다. 칭찬은 엔지니어에게 스팀팩을 놔주는 거 아닐까...

Git 에 관한 필수 용어와 관행(Convention) 또는 약속

master, branch와 origin

* Repository(저장소=줄여서 repo)가 만들어지면(git init) 최초로 유일하게 존재하는 브랜치가 master branch 이고 전체 저장소의 본류가 된다. 이 브랜치는 그 자체로 'master' 라는 이름을 가진다

* 'origin' 은 약속된 이름으로, 현재 push(원격 서버에 업로드) 또는 clone/pull(원격서버로부터 내려받음), Fetch(원격 repo내용 확인) 하려는 원격저장소(서버의 repo)의 기본(default) 이름이다

- git clone git://remote.blah/test.git 을 하게 되면 자동으로 현재 디렉토리에 test 가 만들어지고 원격저장소의 이름은 'origin' 이 된다(~~-o 옵션으로~~ 마지막 인수로 새로운 디렉토리명(예: test_dev)을 덧붙여서 다른 이름을 부여할 수도 있다)

- 굳이 원격저장소의 이름을 origin 으로 하지 않아도 무방하지만, 프로젝트의 최초에 생성되는 원격저장소는 오리지널 이라는 의미의 'origin' 이란 이름을 가지도록 한다

- origin 이 아닌 원격저장소의 이름은 git remote rename oldname newname , git remote rm name1 ... 이런 식으로 변경 또는 삭제가 가능하다. 또는 다른 저장소이름을 origin 으로 바꾸는 것도 물론 가능하다

작업 디렉토리, 로컬/원격저장소(repository), Index, Head

*작업디렉토리는 버전을 관리할 소스 파일들이 있는 곳이며, git init 으로 초기화한 디렉토리와 그 하위 디렉토리 전체가 관리 대상이다. 이 곳의 전체 또는 일부의 파일들은 git add 로 index라는 가상공간에 등록(staging 단계) 되며, Git에 의한 관리 대상이 된다. 수정 또는 새로이 추가된 파일은 항상 git add 명령으로 스테이징단계를 거쳐야 한다

* Staging 단계의 파일들은 git commit 명령에 의해 repo라는 가상 공간에 기록되며, commit 되는 각 단계의 Head^[각주:1] 내용이 기록된 시간 순서대로 꼬리를 물고 늘어서 있는 구조이다. commit 시에 저장되는 내용은 파일 전체 내용이 아닌, 각 파일들의 변경사항들이 묶음으로 기록됨으로써 빠르고 가벼운 동작이 잘 유지된다.

* Git에서 repository는 로컬(development)과 원격에 각각 존재하므로, 개념을 잘 구분해서 써야한다

Git protocol

* Git이 원격저장소와 통신하는 방식은 4가지가 있다

- 로컬 프로토콜: 로컬 디스크나 NFS로 연결된 저장소일 경우 file:///디렉토리/xxx.git 과 같은 방식으로 연결

- SSH프로토콜: ssh를 통한 암호화된 통신 방식으로 ssh를 이용할 로그인 계정이 있을 때 사용할 수 있다. 공개용 프로젝트에는 부적합하다

- Git프로토콜: SSH와 유사하지만 전송 속도가 빠르며 TCP 9418port를 사용한다. 별도의 인증수단이 없어서 Gitosis 와 같은 별도의 인증패키지를 사용해야 한다

- HTTP/HTTPS 프로토콜: 의미 그대로 HTTP 또는 HTTPS 프로토콜을 그대로 사용하며, 방화벽에 크게 구애받지 않는다

Log 와 Commit Identifier

* Git으로 수행한 모든 commit들은 빠짐 없이 저장소에 기록되며, 각 commit 단계별로 유일한 Key(해시 키) 값(예: f6f9e... 처럼 생긴 16진수들) 이 관리된다.

* git log --graph 와 같은 명령으로 이 Key 값을 조회한 후 revert(되돌리기), cherry-pick(브랜치 가져오기), Tag(꼬리표 달기) 등의 명령을 수행하게 된다

Tag 달기

* Git에서 수행한 commit 단계(의 Key 값)에 대해 의미를 가진 꼬리표를 달아서 버전관리의 이정표를 구분하도록 한다

- 예: git tag 1.0.0 edbbca65716825e770d1509e9359612260c08c73

Git 과 전문가들이 권고하는 관행(Convention)

reponame.git 형태로 repository 디렉토리명을 쓴다

유일한 오리지널 저장소(repo)인 경우 원격 저장소에 "origin" 이라는 이름을 붙여 쓴다

Branch 의 종류와 네이밍 관행

Vincent Driessen 이 제시하는 브랜칭 모델

backlogtool.com/git-guide 에서 정리한 브랜칭 모델. 위와 모델은 같으나 단순화 되어 눈에 더 잘 들어온다

* Main 브랜치: Master, Develop

* Supporting(Topic) 브랜치: Feature, Release, Hotfix

- Feature 브랜치: Develop 에서 분기하는 일종의 Topic 브랜치(들), 완료되면 Develop에 병합(merge)한 후 Push

- Release 브랜치: Develop 에서 릴리즈를 위한 분기(release-브랜치명), 완료되면 Master에 병합한 후 release 태깅

배포 후 Develop에 병합

- Hotfix 브랜치: 긴급 수정 작업, Master 에서 긴급 수정작업을 위한 분기(hotfix-브랜치명), 완료되면 Master에 병합, 배포 후 Develop에 병합

[참고] 이 브랜칭 모델이 모든 경우에 정답일 수는 없다. 프로젝트나 사업의 성격상, 어떤 경우는 여러 개의 Release가 고객사별로 브랜칭되어 동시에 병행/교차되어 진행되는 복잡한 구조가 더 적합할 수도 있다. 단, 관리의 복잡성으로 인한 부담이 너무 크지 않다면 말이다. 결국 Git 라는 Tool 자체의 자유도로 인하여, 기존의 SVN등으로 해결 못하던 많은 한계점들을 피해갈 수 있는 가능성이 생겼다는 것은 분명해 보인다.

도움이 되는 온라인 실습/강의/설명 자료

[한글로 된 친절한 문서 페이지들]

https://git-scm.com/book/ko/v2

http://backlogtool.com/git-guide/kr/

http://www.slideshare.net/einsub/svn-git-17386752

http://sapeyes.blog.me/70118257910

https://opentutorials.org/module/217

http://www.creativeworksofknowledge.com/2014/09/03/git-intro-and-common-workflow/

[영문으로 된 실습, 설명, 강의 페이지들]

http://pcottle.github.io/learnGitBranching/ - 한글(일부만) 지원

http://gitref.org/

https://www.atlassian.com/git/tutorials/