Eclipse에서의 Git 활용 - 1: git 개요

Git의 이해

Git은 잘 알려져있듯이 분산형 버전 관리 시스템이다.

git에 대해서 거의 감이 없는 경우라면 생활코딩의 강의가 큰 도움이 된다.

opentutorials.org/module/3733

GIT1

 

추가로 git에 대해 상세하고 체계적으로 알아보고 싶다면 아래를 참조한다. git-scm.com/book/ko/v2

Git - Book

한글로 이렇게 좋은 문서들이 만들어지는게 정말 다행스럽다.

 

이번 시리즈 포스트에서는 eclipse에서 사용법 위주로 다룰 계획이다.

 

핵심 컨셉

git이란 소스코드를 버전기반으로 효과적으로 관리하기 위해 개발된 분산형 버전 관리 시스템이다.

 

repository

일반적으로 repository(저장소)란 파일이나 폴더 즉 리소스들을 저장해두는 곳이다. git의 repository는 리소스를 저장할 때 파일의 내용과 함께 버전을 관리한다. 따라서 동일한 파일이라도 어떤 버전의 파일인지에 대한 기록이 있어서 특정 버전을 콕 찝어서 사용할 수 있다.

git에서는 두 가지의 repository를 사용한다.

 - local repository: 개발자의 PC에 파일이 저장되는 repository이다.

 - remote repository: 원격 저장소로 일반적으로 전용의 웹 서버에서 관리되며 여러 사람들이 함께 리소스를 공유하기 위해 사용된다.

 

기본적인 작업 흐름

A 개발자는 편집한 내용을 local repository에 commit 후 push/pull 등의 명령을 이용해 remote repository에서 버전을 관리한다. B 개발자는 pull을 통해 remote repository의 내용을 local repository에 내려받은(clone) 후 역시 commit/pull/push 작업등을 진행한다.

 

git의 리소스 상태

git은 리소스의 3가지 상태에 따라서 단계별로 관리하는데 이 과정은 local repository에서 git의 동작을 이해하는데 아주 중요한 내용이다.

리소스의 상태

git은 리소스를 modified, staged, committed의 3가지 상태로 관리한다.

 - modified: 파일을 수정해서 더러워진 단계로 아직 commit 처리되지 않았다.

 - staged(indexed): 수정한 상태의 파일에 commit 할꺼라고 표시해 놓은 상태이다.

 - committed: 파일을 local repository에 안전하게 저장한 상태

 

git의 관리 단계

리소스의 상태들은 git이 리소스를 관리하는 3가지 단계와 연관되어있다.

- working directory는 작업 공간(workspace)이라고 볼수 있고 새로 파일을 만들거나 repository에서 특정 버전의 리소스를 checkout으로 가져와서 사용한다. 이 공간에서 추가, 수정된 파일은 modified 상태가 된다. working directory에 있는 리소스 중 modified 상태의 요소를 staged로 변경하기 위해서 git add 명령이 사용된다.

 - staging area는 working directory에 있는 수정된 리소스들 중 commit 대상으로 표시된 리소스들에 대한 정보를 저장한다. Staging area에 있는 staged 파일을 local repository에 반영하기 위해서 git commit 명령이 사용된다.

 - local repository는 리소스들이 버전별로 안전하게 저장되는 곳이다. 사용자는 checkout 명령을 통해 local repository의 내용을 working directory로 이동시킬 수 있다. 또하 git push 명령으로 remote repository에 보낼 수도 있다.

 

브랜치(branch)

branch는 git의 장점 중 하나 이기도 하고 다른 VCS(Version Control System)과의 차이점이라고 볼 수 있는 매우 고마운 기능이다.

브랜치란?

branch란 나뭇가지처럼 중간에 새로운 가지가 계속 해서 뻗어 나가 나름의 독립적인 작업을 가능하게 하는 것으로 merge를 통해 합칠 수도 있다.

예를 들어 다음의 절차를 생각해보자.

 

master라는 branch는 일반적인 project를 나타낸다고 하자. 개발을 위해 develop branch를 만들어 개발을 하다 개발이 완료되면 master branch에 통합해주고 release 버전을 만든다.

이후 신규 버전을 위한 추가 기능을 개발이 필요하다면 feature branch를 만들어 개발을 진행한다. 만약 release 되었던 S.W에서 문제가 발생했다면 debug branch를 만들어서 release 버전을 디버깅 한다. 분리된 branch들은 서로 독립적인 공간을 갖기 때문에 서로 영향 받지 않고 작업이 가능하다.

이렇게 분리되서 작업하던 branch들은 다시 merge 과정을 거쳐 하나로 합쳐질 수 있다.

 

master branch

master branch는 사실 특별할건 없고 그냥 branch 중이 하나이다. 단지 git project를 시작하면 맨 처음 기본으로 주어지는 branch이고 이름이 뭔가 주역일 듯하지만 특별히 역할이 있는 것은 아니다. 하지만 일반적으로 최종 소스를 저장하는 용도로 사용한다.

최근에는 master / slave에 대한 반감으로 main / sub 라는 이름을 사용하는 추세이다.