본문 바로가기
DevOps/Git

git프로젝트 시작하기

by 오이가지아빠 2021. 3. 11.

#1. git?

오래전부터 Subversion(SVN) 이라는 중앙집중식 버전관리(Version Control System)를 이용해 왔다.

이러한 중앙집중식 버전관리(CVCS)는 여러명의 개발자가 작업한 이력을 중앙에서 관리하기가 쉽다.

다만, 이 CVCS환경은 몇가지 치명적인 결점이 있다.

 

가장 대표적인 것이 중앙 서버에 발생한 문제다. 만약 서버가 다운되면 그동안 아무도 다른사람과 협업할 수 없고, 데이터가 있는 하드디스크에 문제가 생긴다면 프로젝트의 모든 히스토리를 잃는다.

이 히스토리는 절대 복원할 수 없고, 오로지 사람들이 가진 1본의 스냅샷만 유지될 뿐.

 

이제 DVCS(분산 버전 관리 시스템)에 대해 얘기해보자.

git, Bazaar 등의 DVCS는 단순히 프로젝트의 마지막 스냅샷만을 Checkout하지 않는다. 그냥 저장소를 히스토리와 더불어 전부 복제한다. 서버에 문제가 생겨도 아무 사용자나 골라서 서버를 복원하면 히스토리를 포함한 모든 데이터가 유지된다.

git은 거의 모든 명령이 로컬파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요없다. 따라서 SVN에 비해 속도가 아주 빠르고, 오프라인에서도 커밋이 가능하다.

예를 들어 프로젝트 작업 중, 이 파일의 히스토리를 조회하고자 할 때, SVN은 서버가 다운되면 아예 조회가 불가능하고 서버에 접속이 되더라도 네트워크 속도에 따라 조회시간이 천차만별이지만, git은 로컬에서 모든 작업을 수행하기 때문에 인터넷이 불가능한 상황에서도 얼마든지 히스토리를 조회하고 수시로 커밋할 수 있다. 이는 매우 사소해 보이지만 실제로 이 상황에 마주하게 되면 느껴지는 차이는 매우 크다.

 

우리는 앞으로 SVN대신 git을 사용하게 될 것이다.

 

#2. Commit? Branch?

기존 SVN환경에서는 Commit자체가 새로운 스냅샷을 만들면서 중앙저장소에 저장하는 행위를 뜻한다면 git에서는 이 역할이 분리되어 있다.(대부분 commit과 동시에 push를 하겠지만)

 

  • git 디렉토리 - git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다.
  • staging area - git 디렉토리 안에 존재하며, 곧 커밋할 파일에 대한 정보를 저장한다. 파일을 수정하면 그 파일의 상태는 Modified이고 git add를 통해 staged 상태가 된다.
  • commit - staging area에 있는 staged상태인 결과물을 로컬 git 디렉토리에 영구적인 스냅샷으로 저장한다. 별도의 설정을 하지 않았다면 기본적으로 master branch에 commit된다.

  • branch - git 의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다. 기본적으로 git은 master 브랜치를 만든다. 처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.

#3. 새 브랜치 생성하기

브랜치를 하나 생성해 보자. 아래와 같이 git branch 명령으로 testing 브랜치를 만든다.

$ git branch testing

새로 만든 브랜치도 지금 작업하고 있는 마지막 커밋을 가리킨다. git은 HEAD라는 특수한 포인터가 있다. 이 포인터는 지금 작업하는 로컬 브랜치를 가리킨다. 브랜치를 새로 만들었지만, git은 아직 master 브랜치를 가리키고 있다.

git branch 명령은 브랜치를 만들기만 하고 브랜치를 옮기지는 않는다.

 

git checkout 명령으로 다른 브랜치로 이동할 수 있다.

$ git checkout testing

이렇게 하면 HEAD는 testing 브랜치를 가리킨다.

자, 여기서부터 핵심이다. 커밋을 새로 한번 해보자. 물론 커밋을 할 수 있도록 아무 파일이나 수정한 후에.

$ git commit -a -m 'change something'

testing 브랜치를 바라보고 있는 HEAD는 앞으로 이동했지만, 여전히 master 브랜치는 이전 커밋을 가리킨다.

다시 master 브랜치로 돌아가보자.

$ git checkout master

HEAD가 master 브랜치로 이동했다. 이렇게 되면 현재 작업중인 디렉토리도 그 시점(testing을 커밋하기 전)으로 돌아간다. testing은 여전히 마지막 변경내용을 포함하고 있고, 우리는 다시 master 브랜치로 돌아와서 하던 일을 계속 할 수 있다.

 

다시 한번 파일을 수정하고 커밋을 해보자

$ git commit -a -m 'master change'

갈라지는 브랜치가 생성됐다!

우리는 브랜치를 하나 만들어 그 브랜치에서 일을 좀 하고, 다시 원래 브랜치로 되돌아와서 다른 일을 할 수 있다.

두 작업 내용은 서로 독립적으로 각 브랜치에 존재한다. 커밋 사이를 자유롭게 이동하다가 때가 되면 두 브랜치를 간단하게 Merge 한다. 

 

위의 갈라지는 브랜치는 다른 VCS도구(예를들면 SVN)와 차이가 극명하다.

만약 EOS대응을 한다고 가정했을 때, 기존 SVN에서는 프로젝트를 통으로 복사해서(이 작업만 수분~수십분이 걸릴 수 있다) 새로운 trunk나 branch를 만들고, 중간에 업무 수정사항이 발생하면 원래프로젝트와 복사한 프로젝트 두 군데에 전부 (어쩌면 서로 다른 로직을) 반영 해야 한다.

하지만 git은 순식간에 기존 프로젝트와 분리된 branch를 생성할 수 있고, 언제든지 merge가능하다. 이런 특징으로 인해 개발과정에서 수시로 브랜치를 생성하여 사용하게 된다.

 

to be continued......

반응형

'DevOps > Git' 카테고리의 다른 글

[git] SVN을 Git으로 Migration 하기  (0) 2021.09.17
git fork 해서 공동작업 하기  (0) 2021.03.30
git 풀 리퀘스트 하기  (0) 2021.03.11
git commit 하기  (0) 2021.03.11
git clone 하기  (0) 2021.03.11

댓글