[Code.presso] 2주차-1. 실무자가 알려주는 Git 활용한 프로젝트 관리(1)

sorzzzzy·2022년 1월 14일

IT교육 codepresso 대외활동 무료IT교육 무료코딩교육 코드프레소 코딩강의 코딩이러닝

[Code.presso] Java 웹 개발 트랙 체험단

목록 보기

3/18

Code.presso Java 웹 개발 트랙 체험단 활동 2주차 첫번째 코스로 수강한 강의는 Git 브랜치(branch)와 GitFlow 에 관한 내용이다.

강의 제목은 "실무자가 알려주는 Git 활용한 프로젝트 관리"으로, 자세한 정보는 👇🏻아래👇🏻 링크를 통해 확인할 수 있다.

📌 실무자가 알려주는 Git 활용한 프로젝트 관리 - 강의 정보

✋🏻 포스팅 내 사용된 사진 파일들의 저작권은 모두 코드프레소에 있으며, 강의자료 공유 및 업로드는 불가능합니다.

🏷 Git 브랜치의 이해

✔️ 브랜치란?

기본 브랜치로부터 파생한 독립적인 작업 공간이다.
최신 커밋을 가리키는 일종의 포인터이다.
매우 가볍다!
생성, 이동, 병합에 용이하다.

마스터 브랜치는 첫번째 커밋이 생성된 이후에 해당 커밋을 가리키게 된다.

✔️ master 브랜치와 HEAD

1️⃣ master 브랜치
Git 은 기본적으로 master 브랜치를 생성하는데, master 브랜치는 첫번째 커밋이 생성되어야 해당 커밋을 가리킬 수 있다.

이를 확인하기 위해, MainService.java 파일을 만들어 커밋을 생성해 보았다.

git log 를 통해 결과를 확인해보자!
➡️ 이와같이 HEAD 가 master 브랜치를 가리키고 있는 것을 확인할 수 있다.

잠깐 여기서, 그렇다면 HEAD는 뭘까 🤔?

2️⃣ HEAD

HEAD 는 현재 브랜치를 가리키는 일종의 포인터로, 현재 브랜치의 마지막 커밋에 대한 스냅샷이다.

만약 브랜치를 이동하게 되면 HEAD 도 변하게 된다.

🏷 브랜치 생성과 이동

✔️ 브랜치 생성

브랜치 생성은 git branch [생성할 브랜치명] 명령어를 통해 이루어진다.

실습에서는 로그인 기능을 구현하는 브랜치를 만든다 가정하고 feature-login 이라는 브랜치를 생성했다.

브랜치 생성 후 git branch 명령어를 통해 현재 브랜치를 알 수 있다.

✔️ 브랜치 이동

브랜치는 git checkout [이동할 브랜치명] 명령어를 통해 이동할 수 있다.

git branch 를 통해 브랜치가 잘 바뀐 것을 확인할 수 있다.

git log 를 통해 히스토리를 확인해보면, HEAD 가 브랜치 이동으로 인해 feature-login 브랜치를 가리키도록 바뀐 것을 확인할 수 있다.

📌 브랜치 관련 다양한 명령어

브랜치 생성과 이동을 동시에 할 때
➡️ git checkout -b [브랜치명]

모든 브랜치의 히스토리를 보고 싶을 때
➡️ git log --all

분기별로 그래프 형태로 보고 싶을 때
➡️git log --all --graph
➡️ 각각의 브랜치들이 현재 어떤 커밋을 가리키고 있는지 확인하기 위해서는 git log 보다 git branch -v 가 효과적이다.

🏷 브랜치 이슈 발생

이슈를 다루기 위해 실습을 통해 브랜치마다 각각의 예제 파일을 작성하고 커밋을 진행했다.
현재까지의 커밋은 총 4개이고 커밋 1,2,4는 master 브랜치에서, 커밋 3은 feature-login 브랜치에서 생성되었다.

실제 개발 중 발생할 수 있는 이슈를 다루는 issue 브랜치를 생성했다.
➡️ git checkout -b issue

커밋이 아직 생성되지 않았기 때문에, issue 브랜치는 지금 아무것도 가리키고 있지 않다. MainService.java 의 코드를 일부 수정하여 커밋을 생성했다.

커밋을 생성하면 위와 같은 형태가 되고, 이슈 해결이 완료됐기 때문에 이제 issue 브랜치의 모든 내용을 master 브랜치로 옮겨야 한다.

🏷 브랜치 병합과 삭제

✔️ 브랜치 병합

issue 브랜치의 모든 내용을 master 브랜치로 병합(Merge) 해보자.

브랜치 병합에 있어서 중요한 점은, 기준이 되는 브랜치로 이동해서 병합해야 한다는 것이다.
여기서는 master 브랜치가 기준이 되므로, master 브랜치로 체크아웃하고 병합을 진행해야 한다.

병합은 git merge [합쳐질 브랜치명] 명령어를 통해 이루어진다.
➡️ git merge issue

merge 를 진행하고 나면, 이러한 결과가 나타난다.

여기서 Fast-forward 란 브랜치의 위치만 최신 커밋으로 이동시키는 방식 이다.

✔️ 브랜치 삭제

원만한 협업을 위해서는 더 이상 사용되지 않는 브랜치는 그때 그때 삭제하는 것이 좋다.

브랜치 삭제는 git branch -d [삭제할 브랜치명] 명령어를 사용하면 된다.
➡️ git branch -d issue

git branch 를 통해 확인해보면, issue 브랜치가 삭제되어 있는 것을 확인할 수 있다.

issue 브랜치에 있는 모든 내용이
master 브랜치로 합쳐지면서, HEAD 포인터가 issue 브랜치의 마지막 커밋이었던 Commit 5 를 가리키는 것을 확인할 수 있다!

참고로💡 브랜치를 삭제할 때 실제 내부적으로 소스코드 커밋들이 삭제되는 게 아니라, 단지 issue 라는 브랜치, 즉 일종의 포인터가 삭제되는 것이다.

🏷 브랜치 충돌 해결

브랜치 병합은 항상 성공적이지만은 않다.
사실 실제 개발을 진행하다 보면 충돌이 생기는 경우가 훨씬 더 많다!

개발하는 기능의 목적에 맞게 어떤 변경사항을 어떻게 반영할지를 결정하고, 수정하고 반영하는 것을 conflict를 해결하는 과정이라고 한다.

충돌을 해결하는 방법은 2가지가 있다.
1️⃣ 직접 merge 하기

vi 명령어로 직접 파일을 수정하는 방법

2️⃣ mergetool 사용하기

툴을 사용하여 직관적이고 쉽게 수정하는 방법

브랜치 충돌 해결 과정을 실습하기 위해, feature-login 브랜치에서 MainService.java 파일을 수정했다.

일부러 충돌이 발생하게 수정을 했기 때문에 커밋을 하게 되면 위와 같은 에러가 발생한다.

이번 실습에서는 충돌을 해결하는 방법 중 두번째 방법인 mergetool 을 사용하기 때문에 git mergetool 명령어를 실행하고, vimdiff 를 입력해준다.

💡 필자는 git mergetool 명령어를 실행했을 때 에러가 떠서, git config merge.tool vimdiff 명령어를 사용했다.

vimdiff 로 들어오게 되면, 이와 같은 화면이 뜬다. 아래의 창은 코드를 수정하는 칸인데 위의 칸은 무엇이고 왜 세칸일까🤔?

이전의 issue 브랜치를 병합할 때는 Fast-forward Merge 방식으로 병합을 했다.

그러나 feature-login 브랜치는 3-way Merge 방식으로 병합을 진행한다.

3-way Merge 방식은 아래 3개의 커밋을 고려하여 병합하는 방식으로,
이 병합의 결과는 새로운 커밋으로 생성된다.
1) master 와 feature-login 브랜치의 공통 부모 커밋
2) master 브랜치의 최신 커밋
3) feature-login 브랜치의 최신 커밋

사진과 같이 병합의 결과로 새로운 Merge Commit 이 생성된다.