[Git] Git의 기본 개념과 Git 사용법에 대해 알아봅시다.

 

 

안녕하세요.

 

 

오늘은 Git의 기본적인 개념에 대해서 알아보고자 합니다.

 

누구나 처음 개발자로서 협업을 시작하게 되면 Git과 같은 프로젝트 관리 시스템을 경험하게 됩니다.

 

하지만 처음 겪는 만큼 어떤 방식으로 프로젝트가 관리되어 가는지, 본인은 어떻게 프로젝트에 관여할 수 있는지 이해하지 못하고 있는 경우가 많은데요.

 

오늘은 위와 같이 Git에 대해 미리 접해보지 못하고 협업을 경험하게 되어 막막하실 분들을 위해 Git개념 정리를 해보겠습니다.

 

시작해볼까요?

 

 

Git은 '분산형 버전 관리 시스템'입니다.

 

Git을 사용하면 프로젝트에 관여하는 개인 사용자 하나하나가 분산적인 본인만의 프로젝트 버전을 갖게 됩니다.

 

자신이 업데이트 한 프로젝트를 업로드하거나, 버전을 특정해서 가져오는 등 프로젝트 버전 관리에 유용한 기능들을 제공합니다.

 

하지만 각각의 사용자가 한 번에 파일을 업로드하거나, 같은 파일을 동시에 수정하게 된다면 메인 프로젝트에서 수정 사항에 대한 충돌이 발생할 수 있겠죠?

 

Git에서는 이러한 충돌을 방지하기 위해 각자의 브랜치(branch)에서 개발하고, 개발한 파일을 업로드할 시 충돌 유무에 따라 경고 메시지를 주게 됩니다.

 

이런 검사 프로세스로 인해 안정적으로 프로젝트를 관리할 수 있게 되는 것이죠.

 

위에 브랜치라는 개념을 언급했는데요.

 

브랜치가 뭘까요?

 

 

* 브랜치(branch)

 

브랜치는 각자의 독립적인 작업 공간을 의미합니다.

 

협업하여 프로젝트를 개발할 땐 동일한 소스코드를 함께 공유하고 다루게 되는데, 이렇게 동일한 소스 코드를 기반으로 서로 다른 작업을 필요로 할 때에 개인마다 독립적인 작업 공간이 있으면 좋겠죠? 

 

이럴 때에 브랜치를 활용하게 됩니다.

 

각자 필요에 의해 브랜치를 만들고 각 브랜치는 서로 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있게 됩니다.

 

예를 들자면 A 브랜치에선 버전 업그레이드, B 브랜치에선 기능 추가, C 브랜치에선 버그 수정 이렇게 분할 작업을 진행할 수 있게 되는 거죠.

 

저장소를 처음 만들게 되면 Git은 master라는 브랜치를 자동적으로 만들어 줍니다.

 

새로운 브랜치를 생성하지 않는다면 모든 작업은 기본적으로 master 브랜치에서 이루어지게 되죠.

 

보통 협업 프로젝트를 하게 되면 자신의 브랜치를 생성하고, 각자의 브랜치에서 작업한 내용들을 master 브랜치로 병합(merge)하게 됩니다.

 

이렇게 master로부터 기능 추가나 버그 수정과 같은 단위 작업을 위해 생성된 브랜치를 피쳐 브랜치(또는 토픽 브랜치)라고 합니다.

 

 

* 작업 브랜치 변경(checkout)

 

협업 시에 Git에선 작업 전에 작업할 브랜치를 선택해야 하는데요.

 

기본적으로 master 브랜치가 선택되어 있지만, 본인만의 브랜치에서 작업을 하려면 checkout 명령어를 이용해 작업 브랜치를 옮겨줘야 합니다.

 

git checkout [옵션] [작업브랜치 이름]

 

위와 같이 checkout 명령어를 이용하면 원하는 작업 브랜치로 이동할 수 있게 됩니다.

 

옵션 값에 -b 옵션을 준다면 이동할 브랜치가 존재하지 않을 때 입력해준 이름으로 새로운 브랜치를 생성해주고 이동하게 됩니다.

 

자세한 옵션 정보는 여기를 참조해주시기 바랍니다.

 

 

* 변경 내용 임시 저장소(stash)

 

커밋하지 않은 변경 내용이 남아있는 채로 브랜치를 전환(checkout)하면 전환한 브랜치에서 변경 내역들에 대해 커밋을 할 수 있게 됩니다.

 

하지만 변경 내용이 남아있는 채로 checkout을 할 시에 checkout 목적지 브랜치와 변경내용이 충돌할 때는 checkout이 실패하게 되는데요.

 

이럴 때 사용하는 기능이 바로 stash입니다.

 

stash란, 파일의 변경 내용을 일시적으로 기록해두는 영역을 말합니다.

 

git stash git stash pop

 

git stash 명령어는 충돌할 수 있는 사항에 대해 stash(임시 저장소)에 저장하게 해 줍니다.

 

이렇게 충돌 가능성이 있는 변경 사항들이 있다면, 변경 사항들을 git stash 명령어를 활용해 stash에 저장해둔 채로 checkout을 진행합니다.

 

변경 사항에 대해 stash에 저장해두기 때문에 충돌 없이 checkout을 진행할 수 있는데요.

 

하지만 checkout을 진행한 뒤에 stash pop 명령어로 저장해둔 변경내용을 꺼내게 되면 애초에 충돌 여지가 있는 데이터를 저장했기 때문에 꺼낼 때 당연히 충돌이 발생하겠죠?

 

이때 Git은 충돌하는 사항들에 대해서 어떤 브랜치의 내용을 가져올지 선택할 수 있게 해 줍니다.

 

본인이 원하는 코드를 선택하여 checkout 한 브랜치에 반영해줄 수 있는 것이죠.

 

 

* 브랜치 병합하기(merge, rebase)

 

브랜치를 병합하는 방법을 알아보겠습니다.

 

* merge

 

자신이 작업하던 브랜치를 원하는 브랜치로 병합합니다. (여기선 master브랜치로 예시를 들겠습니다.)

 

자신의 피쳐 브랜치를 생성한 이후 작업 사항을 master로 업로드 할 때 master 브랜치에 다른 변경 이력이 없을 때는 손쉽게 merge 됩니다.

 

하지만 피쳐 브랜치를 생성한 이후 master 브랜치에 변경 사항이 발생했다면, 본인의 코드와 충돌이 일어날 수 있겠죠.

 

본인이 생성한 브랜치가 생성된 시점이 현재 master 브랜치 최신 소스와 일치하지 않기 때문인데요.

 

이럴 때에는 master 브랜치와 피쳐 브랜치의  변경 사항을 하나 하나 살펴보며 통합 시켜줄 필요가 있습니다.

 

그리고 그 작업은 여간 번거로운 게 아니죠.

 

이럴 때 사용하면 유용한 개념이 rebase라는 개념입니다.

 

* rebase

 

rebase는 본인의 피쳐 브랜치를 master 브랜치로 merge 하기 전 자신의 작업 브랜치를 마치 최신의 master 브랜치에서 피쳐 브랜치를 생성한 것처럼 변경해줍니다.

 

그리고 merge 할 때는 본인의 변경 사항들이 master 브랜치의 내용과 충돌할 일을 없애주는 것이죠.

 

간단한 그림으로 설명하자면 아래 이미지와 같습니다.

 

(출처 : https://backlog.com/git-tutorial/kr/stepup/stepup1_4.html)

 

피쳐 브랜치를 master 브랜치로 merge 하는 방법을 간단하게 정리하면 아래와 같습니다.

 

• rebase로 피쳐 브랜치에 master 브랜치의 최신 코드를 적용한다.
• master 브랜치에 피쳐 브랜치의 변경 내용을 merge 시킨다.

 

 

<참고할만한 성공적인 Git 브랜칭 모델>

 

Git의 대표적인 브랜치 운용 모델입니다.

 

이 운용 모델에서는 크게 5가지 종류의 브랜치를 이용하여 개발을 진행합니다.

 

(1) master 브랜치

master 브랜치는 기본적으로 배포 가능한 상태만을 관리합니다. 커밋할 때 관용적으로 태그를 사용하여 배포 번호를 기록합니다.

 

(2) develop 브랜치

통합 브랜치의 역할을 합니다. 평소에는 이 브랜치를 활용하여 개발을 진행하게 됩니다.

 

(3) feature 브랜치

이 브랜치는 기능 개발 및 버그 수정과 같은 상황에 develop 브랜치로부터 생성되어 개발을 진행하고, 개발이 완료되면 develop 브랜치로 병합하여 공유합니다.

 

(4) release 브랜치

릴리즈 브랜치는 개발된 develop 브랜치를 master 브랜치로 병합하기 전 동작과 기능에 대한 테스트를 진행합니다.

관용적으로 해당 브랜치의 이름 앞에는 'release-'를 붙입니다.

 

(5) hotfix 브랜치

배포한 버전에서 긴급한 수정 사항이 발생할 경우 master 브랜치에서 분기하여 hotfix 브랜치에서 수정하게 됩니다.

관례적으로 브랜치 이름 앞에 'hotfix-'를 붙입니다.

 

여기까지 기본적인 Git의 기본 개념과 활용도에 대해서 살펴보았습니다.

 

 

Git은 협업에서 사용할 시 정말 유용하지만 동시에 많은 복잡한 개념이 들어있어 완전히 이해하고 사용하기 어려운 버전 관리 툴인 것 같아요.

 

하지만 Git의 개념을 제대로 이해해 두신다면 실무에서 정말 많은 도움이 될 것이라 확신합니다.

 

다음 글에서는 Git을 이용하여 직접 프로젝트를 관리하는 방법과 또 다른 유용한 Git 명령어들에 대해서도 알아보겠습니다.

 

감사합니다.