Get Up & Code, MacKin Talk

깃(Git)&깃허브(Github) 배우기 -5(깃과 브랜치) 본문

Computer Science/Git,Github

깃(Git)&깃허브(Github) 배우기 -5(깃과 브랜치)

맥킨 2021. 2. 19. 22:16

깃& 깃헙 배우기 시리즈
내용이 잘 이해되지 않는다면 이전 포스팅을 차례로 확인하실 것을 추천드립니다.

2021/02/14 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -1

2021/02/15 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -2(깃 저장소 만들기)

2021/02/16 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -3(커밋 확인 및 버전 관리)

2021/02/18 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -4(커밋 되돌리기, reset, revert)


포스팅 개요.

지난 포스팅에서 수정한 내용을 취소하고,가장 최신 버전 상태로 되돌리는 방법에 대해 수정, 스테이징, 커밋 단계로 나눠 소개해 드렸습니다.

이번 포스팅에서는 브랜치가 무엇인지에 대해 소개해드리려고 합니다.

브랜치란 영어 단어 그대로 가지라는 뜻을 가집니다.

예전 첫번째 포스팅에서 깃을 사용하면 파일의 버전 관리를 할 수 있다고 했었는데, 이번 포스팅에서 해당 내용에 대해서 함께 다뤄볼 수 있지 않을까 생각합니다.

상단 그림은 이전 포스팅까지에서 브랜치 추가 없이 버전 관리를 진행하는 방법에 대해서 그림으로 나열해보았습니다.

커밋도 진행하지만, 스테이징을 했다가 다시 스테이지 영역에서 내리기도 하고.. 반복 반복..

물론 공통된 내용을 기반으로 한 가지를 작성한다면 상관 없을 수 있지만, 하나의 프로그램을 기반으로 여러 버전을 제공해야 한다면 여러 버전을 각각 저장하는 것은 공간 낭비를 초래할 수 있습니다. 또한 여러 버전을 한 프로그램 내에 포함하는 것도 어렵습니다.

하지만 브랜치를 이용한다면 수정 내역에 대한 반영을 브랜치 별로 나눠 다른 브랜치에서 수정이 일어나더라도 다른 브랜치에는 반영이 되지 않기 때문에 브랜치 별로 개발을 진행하고, 이를 나중에 반영할지를 결정할 수 있습니다.

제가 그림으로 설명을 대체해보려고 했는데, 그림을 잘 못 그렸네요..

각 개별 브랜치는 작업 중 다른 브랜치에 영향을 받지 않기 때문에 동시에 독립적인 여러 작업이 진행될 수 있도록 하는 역할을 하고, 브랜치는 합칠 수 있기 때문에 독립적인 작업이 추후 합병될 수 있다는 특징을 같이 알고 계시는 게 좋을 듯합니다.

그럼 브랜치를 직접 같이 만들면서 설명을 드리도록 하겠습니다.

저는 다음과 같이 mkdir 명령어를 사용해 manual이라는 폴더를 만들고, 해당 폴더로 이동해 git init 명령어를 입력해주었습니다.
이후

vim 편집기를 실행해서 총 3번 커밋을 진행해주었습니다. 브랜치를 다루기 위한 실습이라고 보시면 될 듯합니다.

vim work.txt 입력 후 수정 및 저장
git add work.txt
git commit -m "work 1"  

vim work.txt 입력 후 수정 및 저장
git commit -am "work 2"

vim work.txt입력 후 수정 및 저장
git commit -am "work 3"  

저는 중간에 git status 명령어로 깃 상태도 한번 확인해주었습니다.

이후 git log를 입력해 깃 로그를 확인해보았습니다.

다음과 같이 최신 커밋인 work 3 커밋 옆에만 (HEAD -> master)이라고 적힌 것을 확인할 수 있습니다.
이는 현재 HEAD가 master 브랜치를 가리키고 있음을 알려줍니다.

 

아직은 브랜치를 따로 만들지 않았는데, 이제부터 직접 브랜치를 만들어 좀 더 이해해보도록 하겠습니다.

먼저 브랜치를 만들거나 확인하기 위한 명령어인 git branch를 입력해주도록 하겠습니다.

git branch

입력 후 Enter을 누르고 나면, 다음과 같은 창을 볼 수 있습니다.

현재는 마스터 브랜치 하나만 존재하는 것을 확인할 수 있습니다. 지난 포스팅들을 모두 포함해 그동안 저희는 마스터 브랜치에서만 작업을 했다고 말할 수 있습니다.

 

이제 새로운 브랜치를 만들어보도록 하겠습니다. 명령어는 git branch (만들 브랜치 이름)입니다.

git branch kakao

명령어를 입력하겠습니다. 이후 다시 git branch 명령어로 브랜치를 확인해보면 kakao라는 이름의 브랜치가 추가된 것을 확인할 수 있습니다.

카카오 가고싶다..

하지만 master 브랜치 앞에는 *이 붙어있는 것을 확인할 수 있습니다. 여기서 *는 현재 작업하고 있는 브랜치를 의미합니다.
브랜치를 추가한 이후에 git log 명령어로 한번 더 깃 기록을 확인해보겠습니다.

 

하단처럼 단일 브랜치가 아닌 다음과 같이 master 브랜치 외의 타 브랜치(kakao)가 생기고 나면 git log의 출력 결과도 다른 양상을 보여줍니다.

상단에 표기된 (HEAD -> master, kakao)를 보시면 branch를 추가하기 전과는 다르게 kakao 브랜치가 추가된 것을 확인할 수 있습니다.
이 표기는 브랜치는 master과 kakao가 있고, HEAD -> master이므로 현재는 master 브랜치를 작업한다.라고 설명이 가능합니다.

 

여기서 HEAD가 계속 나오는데 C/C++에서의 포인터 같은 개념이라고 생각해볼 수 있습니다. 현재 작업 중인 브랜치를 가리킨다고 생각하시면 됩니다. 현재 master 브랜치에서 작업을 진행하고 있기 때문에 HEAD가 master 브랜치를 가리키는 게 맞겠죠.

 

여러 테스트를 위해 다른 브랜치 몇 개를 추가해 보겠습니다.

같은 방법으로


git branch (브랜치 이름)

의 순으로 기재해주면 됩니다.

다시 git branch 명령어를 입력해 브랜치 목록을 확인해보겠습니다.

가고싶은 곳들..

이제 브랜치가 총 4개가 된 것을 확인할 수 있고, 현재 작업 중인 브랜치는 *이 붙은 master 브랜치임을 확인할 수 있습니다.

브랜치를 여러 개 만들었다면, 각 브랜치 마다 개별적인 작업이 진행이 가능한데, 먼저 브랜치 간 이동을 해보도록 하겠습니다.


git log 명령어를 입력해보면 다음과 같이 여러 브랜치에 대한 내용이 함께 기재되어 있는 것을 확인할 수 있습니다.

브랜치를 옮기기 전 먼저 현재 있는 master 브랜치에서 커밋을 한번 진행해보겠습니다.

vim 편집기로 앞서 만든 work.txt 파일을 일부 수정하고, 커밋 명령어를 이용해 커밋을 하고,


vim work.txt

git commit -am "master content 4"

git log 명령어에 --oneline 옵션을 주고 결과를 출력해보았습니다.

git log --oneline  

이전에 찍었던 로그와는 사뭇 다른 것을 확인할 수 있는데, HEAD는 master 브랜치를 가리키고 있으며, master branch의 경우, 최신에 커밋을 했으므로, 새롭게 커밋된 내용을 반영하고 있고, 나머지 naver, kakao, hyperconnect 브랜치의 최신 커밋은 work 3 메시지를 포함한 커밋 내용을 반영하고 있다고 말할 수 있습니다.

 

이제 현재 브랜치였던 master 브랜치로부터 다른 브랜치 kakao로 이동해보겠습니다.

브랜치 이동 명령어는 git checkout 입니다.


git checkout (브랜치 이름)

순으로 입력하면 되고, 저는 다음과 같이 kakao 브랜치로 이동하는 명령어를 작성해 출력 결과를 확인해보았습니다.

이제 명령어 맨 뒤에 master 브랜치가 kakao 브랜치로 옮겨간 것을 확인할 수 있습니다.

 

로그를 한번 더 출력해보도록 하겠습니다.

앞서 HEAD가 master 브랜치를 가리키던 상황과는 다르게 master 브랜치의 최신 커밋을 반영하지 않고 있으며, 분기하기 전까지의 공통 내용들만 복사된 것을 확인할 수 있습니다. 또한 현재 HEAD는 kakao를 가리키고 있는 것 또한 함께 확인할 수 있습니다.

 

분기된 master 브랜치는 더 이상 반영이 되고 있지 않네요.

그러면 직접 kakao 브랜치의 내용을 확인해 앞서 설명드린 것처럼 마지막 커밋이 반영이 안 된 것이 맞는지 확인해 보도록 하겠습니다.

위의 이미지와 같이 kakao 브랜치에서는 work.txt 파일이 content3까지, master 브랜치의 경우 content4까지 내용에 반영되어 있는 것을 확인할 수 있습니다. 이로부터 kakao 브랜치가 master 브랜치에서 분기된 이후부터는 master 브랜치의 커밋 내용을 반영받지 않는 것을 볼 수 있었습니다.

 

그러나 이처럼 브랜치를 계속 늘여 나가다 보면 분명 어떤 브랜치에서 커밋이 이뤄질 때마다에 대한 혼선이 생길 수 있기 때문에 브랜치의 정보를 확인하는 방법에 대해 말씀드리겠습니다.

 

이번에는 master 브랜치가 아닌 현재 옮겨온 kakao 브랜치에서 새로운 브랜치를 만들어 보도록 하겠습니다.

먼저 kakao 브랜치에서 work.txt 파일에 내용을 추가하고, 이를 커밋하였습니다.
git log를 확인해보면 다음과 같이 확인할 수 있습니다.

git log --oneline

git log --oneline --branches 명령어를 이용할 경우에는 다음과 같이 각 브랜치의 커밋 정보도 함께 볼 수 있습니다.

git log --oneline --branches

각 브랜치마다 커밋 정보가 달라 반영된 내용이 다른 것도 함께 확인할 수 있습니다.

하지만 이경우도 브랜치와 커밋의 관계를 파악하기 조금 불편한 점이 있는데, --graph 옵션을 추가해 출력해 보겠습니다.

빨간색 선을 따라가 보면 work3 커밋으로부터 kakao 브랜치와 master 브랜치가 각각 분기했음을 확인할 수 있습니다.

 

work3까지는 내용이 같지만, 이후로는 반영된 내용들이 다름을 알 수 있는 것입니다.

하지만 커밋이 쌓여갈수록 브랜치 사이에 어떤 차이가 있는지 확인하는 것은 어렵습니다.

이런 상황을 위해 깃은 차이점을 확인하기 위해 도와줍니다.

git log master..kakao // master 브랜치엔 반영되지 않고, kakao 브랜치에 반영된 내용만 보여준다.

git log kakao..master // 위와 반대
명령어를 한 번씩 입력해보겠습니다.

전자의 경우, kakao 브랜치에 반영된 내용만 보여주는 반면,

후자의 경우, master 브랜치에만 반영된 내용을 보여주는 것을 확인할 수 있습니다.

브랜치를 통해 개별적인 작업이 가능한 것을 오늘 소개해 드렸습니다.

 

 

다음 포스팅에서는 브랜치 작업을 진행하다 마무리하고 기존 브랜치와 병합하는 과정에 대해서 알아보겠습니다. 또한 병합 과정에서 같은 문서의 같은 내용을 수정한 경우, 병합 시 브랜치 충돌이 일어나는 경우가 있는데. 이 경우에 해결하는 방법도 함께 알아보도록 하겠습니다.


참고

Do it! 지옥에서 온 문서 관리자 깃&깃허브 입문 / 이지스퍼블리싱

깃헙 :github.com/


깃& 깃헙 배우기 시리즈
내용이 잘 이해되지 않는다면 이전 포스팅을 차례로 확인하실 것을 추천드립니다.

2021/02/14 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -1

2021/02/15 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -2(깃 저장소 만들기)

2021/02/16 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -3(커밋 확인 및 버전 관리)

2021/02/18 - [Computer Science/Git,Github] - 깃(Git)&깃허브(Github) 배우기 -4(커밋 되돌리기, reset, revert)