[Git] 브랜치 관리와 고급 기능

 

1. Git Branch

 

Case 1

로그인, 로그아웃, 회원가입, 마이페이지 기능을 구현하는 일이 남아있어, 각자 팀원끼리 나누어서 구현하려고 합니다. 모든 팀원이 랜딩 페이지의 소스코드를 동일하게 공유하며 서로 다른 작업을 진행할 수 있는 방법은?

Case 2

회사 웹사이트에 개인적으로 추가해 보고 싶은 기능이 생겼습니다. 그런데 아직 주니어 개발자로서 마음대로 회사 웹 사이트의 코드를 건드리기에는 위험 부담이 크게 느껴집니다. 회사 웹 사이트의 코드를 건드리지 않고, 따로 혼자 작업하는 방법은?

 

Git은 개발자들이 협업하기에 최적의 툴이며, 소프트웨어를 개발할 때에 개발자들은 동일한 소스코드를 함께 공유하고 다루게 됩니다. 동일한 소스코드 위에서 어떤 개발자는 버그를 수정하기도 하고 또 다른 개발자는 새로운 기능을 만들어 내기도 합니다. 이처럼 여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없습니다.

 

이런 경우, 여러 개발자가 동시에 서로 다른 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치(Branch)' 입니다.

협업을 하는 상황 뿐만 아니라, 기존의 소스 코드를 해치지 않으면서 다른 작업을 시도해보고 싶을 때에도 이 브랜치 기능을 활용할 수 있습니다. feature 브랜치를 만들어서 원하는 기능을 구현할 수 있습니다. 그리고 feature 브랜치에서 완성한 코드를 기존 소스 코드에 반영해도 문제가 없다면, 그 때 병합(merge) 할 수 있습니다. 브랜치라는 개념은 마치 나무에서 가지를 뻗어 나가는 것과도 비슷합니다.

 

브랜치?

브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다.
개발을 하다 보면 한 페이지 안의 여러 기능을 따로 구현하기 위해, 코드를 여러 개로 복사해야 하는 일이 자주 생깁니다.
브랜치 기능을 활용하면, 코드를 통째로 복사한 후 원래 코드가 변경될 우려 없이 독립적으로 개발할 수 있습니다.

다시 말해, 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.

브랜치 기능의 장점은 다음과 같습니다.

• 한 소스코드에서 동시에 다양한 작업을 할 수 있게 해준다.
• 소스코드의 한 시점과 동일한 상태를 만들고, 브랜치를 넘나들며 작업을 수행할 수 있다.
• 각각의 브랜치에서 생긴 변화가 다른 브랜치에 영향을 주지 않고 독립적으로 코딩을 진행할 수 있다.

 

hotfix, release, develop, feature 등 다양한 브랜치를 만들고 작업을 하다 보면 다음 이미지와 비슷한 Git graph가 만들어집니다.

 

 여러 브랜치를 만든 레파지토리의 Git Graph (이미지 출처 : Git Beginner's Guide for Dummies)

 

master 또는 main 이라는 이름을 가진 통합 브랜치에 뿌리를 두고, 각각의 브랜치가 갈라져 나오고 있는 모습입니다.

이렇게 나누어진 브랜치에서는 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경할 수 있습니다. 분리된 작업 영역(브랜치)에서 변경된 내용들은 다른 브랜치와 병합(Merge)함으로써 다시 새로운 하나의 브랜치로 모을 수 있습니다.

아래 그림을 통해, 브랜치를 사용하여 동시에 여러 작업을 진행할 때의 작업 흐름을 한눈에 파악할 수 있습니다.

[그림] 동시에 여러 작업을 진행하는 Git Graph

여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 통합 브랜치에서 자신의 작업 전용 브랜치를 만듭니다.

그리고 각자의 브랜치에서 맡은 영역에 대한 작업을 진행한 후, 작업이 끝난 브랜치는 통합 브랜치에 병합해서 변경 사항을 적용합니다. 이를 통해 다른 브랜치의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이렇게 작업을 진행하게 되면 '작업 단위', 즉 브랜치로 그 작업의 내용들이 모두 기록되기 때문에 문제가 발생했을 때 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.

 

브랜치 종류

- 통합 브랜치 (Integration Branch)

배포될 소스 코드가 기록되는 브랜치. Github Repository를 생성하게 되면 기본적으로 main 브랜치가 생깁니다. (기존 Repository의 경우 master로 되어 있는 곳도 많습니다.) 해당 프로젝트의 모든 기능이 정상적으로 작동하는 상태의 소스코드가 담겨 있습니다.

- 피처 브랜치 (Feature Branch)

기능 추가, 버그 수정과 같이 단위 작업을 위한 브랜치. 통합 브랜치로부터 만들어내며, 피처 브랜치에서 하나의 작업이 완료가 되면 다시 통합 브랜치에 병합하는 방식으로 진행됩니다. 토픽 브랜치라고도 합니다.

 

 

 

2. 프로젝트 workflow

 

 

프로젝트를 진행하시는 전체 흐름은 다음과 같습니다.

 

Local에서 새로운 브랜치를 생성하고 작업이 끝나면 Remote Repository 로 Push 합니다.


그리고 Project Upstream Repository에 반영(merge)될 수 있도록 Pull Request 합니다.

만약 작업하던 중간에 Remote upstream 에 업데이트가 생긴다면 Local 로 pull 받아주어야 합니다.

 

 

프로젝트 Remote Repository를 만들었어요. 팀원들과 함께 나누어 작업을 하기 위해서 각자의 Remote Repository로 Fork를 하도록 하겠습니다. 그리고 Local에서 작업하기 위해서 git clone 명령어로 Repository를 Local에 가지고 왔습니다.

 

기본적으로 개발을 진행하는 과정에서는 main 브랜치가 아닌 dev 브랜치를 하나 만들어서 작업을 하는 경우가 많습니다. dev 브랜치를 만들어서 해당 브랜치로 이동해 보겠습니다. 여기서 HEAD는 현재 위치의 커밋을 가리킵니다. 즉 현재 작업중인 커밋입니다.

 

git checkout -b dev 명령어를 통해서 dev 브랜치를 생성했습니다. (git switch -c dev 명령어도 가능합니다.) Remote Repository 에도 생성한 브랜치를 반영하기 위해서는 git push origin dev 명령어를 입력해 주셔야 합니다.

 

브랜치가 잘 생성되었는지 확인하고 싶어요. 생성한 브랜치의 목록과 내가 현재 dev 브랜치에 있는 것이 맞는지 확인해 볼 방법은 없을까요? 바로 git branch 명령어를 통해 확인할 수 있습니다. 터미널 창에 git branch 를 입력하면 다음 화면이 뜹니다. 알파벳 q 를 눌러서 종료할 수 있습니다.

 

팀 프로젝트에 들어가기 앞서 회의를 통해 하나의 기능을 구현할 때는 ‘feature/기능이름’ 이라는 브랜치를 만들어서 작업하기로 정했습니다. 로그인 기능을 구현하기 위해서 feature/login 이라는 브랜치를 생성해보도록 하겠습니다.

 

git checkout -b feature/login 명령어를 입력했어요.

git switch -c feature/login 명령어도 같은 기능을 합니다.

 

feature/login 브랜치에서 로그인 기능이 완성되었습니다! 여기에 소셜 로그인(oauth) 기능을 추가해 보고 싶어요. 그런데 잘 만들어 놓은 로그인 코드를 건드리자니 위험 부담이 있네요. 새로운 브랜치를 하나 더 만들어서 작업하고 싶습니다. feature/login-oauth 라는 이름으로 feature/login 브랜치에서 파생된 브랜치를 하나 더 만들어서 작업해 보겠습니다.

 

 

git checkout -b feature/login-oauth 명령어를 입력했습니다. git switch -c feature/login-oauth 명령어도 같은 기능을 합니다.

 

소셜 로그인 기능까지 구현이 완료되었습니다. 이 feature/login-oauth 에 있는 코드를 feature/login 브랜치로 병합(merge) 할 수 있는 방법이 있을까요? 먼저 git checkout(switch) feature/login 명령어를 통해 feature/login 브랜치로 이동하세요.

 

 

git checkout -b feature/login 명령어를 입력했습니다. merge하기 위해서는 먼저 병합이 될 브랜치로 이동을 해야 합니다. 즉 feature/login-oauth 브랜치를 feature/login 브랜치로 병합하기 위해서는 feature/login 브랜치로 이동해야 합니다. git switch feature/login도 같은 기능을 합니다.

 

이제 feature/login-oauth 의 내용을 feature/login 브랜치로 병합하기 위해서는 현재 위치가 feature/login 인 상태에서 git merge feature/login-oauth 명령어를 입력하세요. feature/login-oauth 브랜치가 머지되기 전 feature/login 브랜치에 추가적인 커밋이 없으므로, 브랜치가 분기될 필요가 없습니다. 그러므로 자동적으로 fast-forward 방식으로 병합이 이뤄집니다. fast-forward 방식이란 별도의 커밋을 생성하지 않고 feature/login 브랜치가 가리키는 커밋을 feature/login-oauth 가 생성한 커밋으로 바꾸는 작업을 말합니다.

 

 

만일, feature/login 브랜치에 별도의 커밋이 있었다면, fast-forward가 아닌 merge commit 방식으로 병합되었을 것입니다. 이는 각 브랜치가 줄기처럼 분기한 후, 병합의 모양새를 가집니다.

 

git merge feature/login-oauth 명령어를 입력해 해당 브랜치를 현재 위치한 브랜치로 병합(merge) 할 수 있습니다.

 

 

여기서 잠시 merge와 rebase의 차이점에 대해서 알아보고 갑시다. merge와 rebase의 차이점은 면접 단골 질문이기도 합니다! rebase의 원리가 바로 앞서 배웠던 fast-forward와도 같습니다. merge 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해 집니다. rebase 말 그대로 branch base를 이동시킨다는 뜻으로, 머지처럼 브랜치 통합을 목적으로 하지만, 특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능을 합니다. 그림에서 보이는 것과 같이 feature/login 브랜치에서 git rebase main feature/login 명령어를 입력하면 main의 가장 최신 커밋으로 브랜치가 가리키는 곳이 변경됩니다. (main의 다른 커밋에서 충돌이 없을 경우)

 

로컬의 작업한 내용을 Remote Repository 에 업로드하기 위해서는 push를 해야 합니다.

 

 

git push origin feature/login 명령어를 입력해 해당 브랜치를 Remote Repository로 업로드할 수 있습니다.

 

 

 

feature/login 브랜치의 변경 사항을 다른 팀원들과 함께 코드 리뷰를 하고 dev 브랜치에 적용하고 싶습니다. Github의 Pull Request 기능을 활용해 dev 브랜치로의 반영을 요청할 수 있습니다. 리뷰가 끝난 코드는 브라우저에서도 dev 브랜치로 merge 할 수 있습니다.

 

간단하게 PR 내용을 입력한 후 Create pull request 버튼을 클릭하세요.