안녕하세요. 이번 시간에는 대망의 Git 브랜치(Branch)에 대해 알아보겠습니다. 사실 앞부분은 기본 중에 기본이고요. 지금부터 할 내용이 주요 부분입니다. 다음 두 상황을 가정해보죠.
1) 혼자 작업할 때: 현재 홈페이지를 만들고 있다가 실시간 알림 기능을 추가하고 싶어졌습니다. 하지만 한 번에 만들 수 있을거라는 확신이 없어서 무수히 많은 commit을 해야 완성할 수 있을 것 같습니다. 그리고 실패 시에는 commit을 이전으로 되돌리고 싶은데요. 그렇다고 현재 master 브랜치의 log가 지저분해지는 것은 원하지 않습니다.
2) 협업할 때: A와 B 두 명이서 협업을 하는 상황입니다. Github에 코드를 올려놓고 각자 다운로드받아 코딩을 하고 있습니다. 두 명이 각자 다른 파일을 작업하면 별 걱정이 없겠지만, 하나의 파일을 둘이 동시에 작업하고 있습니다. 문제는 이렇게 여러 명이 같은 파일을 작업해서 commit한 후, 동시에 Github에 push를 하면 충돌이 생긴다는 겁니다. 왜냐하면 A가 한 commit은 B에겐 없고, B가 한 commit은 A에게 없어서 Github 서버는 어떤 것이 올바른 commit인지 알 수 없습니다.
위와 같은 상황에서 우리는 branch 기능을 사용합니다. 기본적으로 생성되는 master 브랜치 말고 다른 브랜치를 만들어 사용하는 거죠. 위의 예시가 다른 브랜치를 사용하는 이유고, 또 하나의 이유는 실제 환경에선 master 브랜치에 배포 준비가 된 commit들만 남기는 경우가 많기 때문입니다.
제 홈페이지를 예로 들자면, 제가 Github의 origin에 master 브랜치의 commit을 push하는 순간 자동으로 제 홈페이지가 업데이트됩니다. 그렇게 설정해 놓았거든요. 만약 실수로 에러가 있는 master 브랜치의 commit을 push하면 제 홈페이지에 에러가 발생하는 겁니다. 그런 상황을 막기 위해, 아예 다른 브랜치를 만들어 작업하면 실수로 에러가 있는 브랜치를 push하더라도 master과는 별개이기 때문에 안심할 수 있습니다.
현재 log를 시간순으로 나열하면 다음과 같습니다. 두 번 commit하고 지난 시간에 revert를 했기 때문에 log가 세 개가 쌓였습니다.
최신 commit인 Revert "Second commit"에 master가 위치해있습니다. master는 master 브랜치의 가장 최근 commit을 가리키고요. HEAD(노란 원)는 현재 내가 작업중인 commit의 위치를 가리킵니다. First commit에는 remotes/origin/master가 있는데 예전에 원격 저장소로 push했음을 표시하고 있습니다.
위와 같이 log를 시각적으로 보려면 프로젝트 폴더에서 Git GUI를 실행하면 됩니다. 실행 방법은 지난 시간에 설명했습니다. 컴컴한 명령 프롬프트보다는 훨씬 낫죠?
git branch
명령어를 통해 새로운 branch를 만들어보죠. git branch [브랜치명]입니다.
잘 생성되었나 보려면 그냥 git branch라고 쳐보세요. 앞에 * 표시가 있는 게 현재 HEAD가 있는 branch입니다.
git checkout
새로 만든 feature 브랜치에서 작업하려면 feature 브랜치로 HEAD를 옮겨야 합니다. 이때 사용하는 명령어가 git checkout [브랜치명]입니다.
git checkout은 예전에 봤죠? 파일에 사용했을 때는 Modified에서 Unmodifed로 상태를 변경하는 명령어였습니다. 브랜치에 사용하는 경우는 브랜치간 전환을 합니다.
git.html을 다음과 같이 바꿉니다.
<!DOCTYPE html>
<html>
<head>
<title>깃 연습</title>
<link rel="stylesheet" href="./git.css" />
</head>
<body>
<h1>깃 브랜치</h1>
<p><b>깃 브랜치</b>의 사용 방법에 대해 알아봅시다</p>
</body>
</html>그리고 Feature commit이란 메세지로 commit해줍니다.
현재 구조는 다음과 같습니다. 새로운 브랜치 feature가 master보다 한 단계 앞서 있습니다. 브랜치별로는 commit이 따로 적용됩니다. 즉 master와 feature은 Revert "Second commit"까지는 공유하지만 그 다음부터는 별개의 프로젝트라고 보셔도 됩니다.
이제 여러 명의 사람들이 작업할 때에는 각자 브랜치를 만들어 따로 작업하면 됩니다. 한 사람의 작업이 다른 사람에게 영향을 미치지 않습니다.
각자 작업을 마치면 최종적으로 하나로 합쳐야겠죠? 이제 master 브랜치에서 하나로 모아줍시다. feature 브랜치에서 작업하다가 다시 git checkout [브랜치명] 명령어를 사용하여 master 브랜치로 돌아갑니다.
분량 관계로 다음 시간에 이어하겠습니다. 두 개의 브랜치를 합치는 두 가지 방법(merge, rebase)에 대해 배워보겠습니다.
그렇다면 예시들어주신 대로 혼자 프로젝트를 진행할 땐 기능별로 브랜치를 나누고 기능들이 검증되면 master에서 합치는 방식으로 관리를 하는 편인가요?(개인마다 다르겠지만..)
아니면 혼자 프로젝트를 진행할 때 브랜치 관리하는 방식 추천 부탁드립니다 ㅎㅎ
언제나 좋은 강의 감사합니다