Git Branch란 ?

▩목 차▩

1.Git Branch

      1-1.Git Branch의 필요성

      1-2.Git Branch란?

      1-3. master 브랜치

      1-4. 브랜치 만들기

      1-5. 브랜치 효과적으로 사용하기

            1-5-1. 대규모 프로젝트에서 사용하는 GitFlow를 통한 효과적인 Git Branch 관리 (feat.배달의 민족)

                  1-5-1-1. Master Branch

                  1-5-1-2. Develop Branch

                  1-5-1-3. Feature Branch

                  1-5-1-4. Release Branch

                  1-5-1-5.  Hotfix Branch

                  1-5-1-6. GitFlow의 전체 흐름

            1-5-2. 소규모 프로젝트에서 사용하는 Feature Branch Workflow를 통한 효과적인 Git Branch 관리

                  1-5-2-1. Feature Branch Workflow를 사용하기 위해 알아야 하는 기본 개념

                  1-5-2-2. Feature Branch Workflow의 방법 및 개념

 

---

 

프로젝트를 시작하기 전, Git Branch에 대해 알아보자. [ 추후에 이것 브랜치를 관리해주는 sourcetree라는 Git 형상관리 툴에 대해 공부 할 예정이다. ]

[ Git Branch를 공부하기 전 Git에 대한 사전지식이 필요하므로 아래 링크를 참고하면 좋겠다.]

Git Hub(깃 저장소)에 업로드하기

---

■ 1.Git Branch ■

 

■ 1-1.Git Branch의 필요성

소프트웨어를 개발할 때에 개발자들은 동일한 소스코드를 함께 공유하고 다루게 된다.

동일한 소스코드위에서 어떤 개발자는 버그를 수정하기도 하고, 어떤 개발자는 새로운 기능을 만들어 내기도 한다.

즉, 여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없다.

==> 이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어주는 기능이 바로 브랜치이다. 이러한 브랜치는 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경 할 수 있고, 이러한 변경된 내용은 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수도 있다.

---

■ 1-2.Git Branch란?

브랜치는 말 그대로 독립적으로 어떤 작업을 진행하기 위한 의미의 말이다.

==> 즉, 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러 작업을 동시에 진행 할 수 있다.

위 그림과 같이 브랜치가 있다고 가정을 할 때, 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 해로운 하나의 브랜치로 모을 수 있다.

예를들어, 나는 비디오 표시 버그 수정 및 새로운 기능 추가에 대한 것을 개발을 하여 각각의 브랜치로 나누었다. 다른 개발자는 사이드 바 추가 기능을 만들어야 했고, 브랜치를 만들어서 진행을 했다.
그리고 추후에 이 기능들을 완벽히 개발했다고 가정하여 각각의 브랜치로 나누어졌던 이것들을 하나의 브랜치와 병합(Merge)를 하여 다양한 기능을 가진 브랜치로 만들 수 있는것이다. 

즉, 쉽게 말해서 자신의 작업 전용 브랜치를 만들고 각자 작업을 진행 후 작업이 끝난 사람은 메인 브랜치에 각자 자신의 브랜치의 변경 사항을 적용한다는 것인데 이것을 풀어서 말해보면 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모을 수 있게 된다.

---

■ 1-3. master 브랜치

그러면 맨 처음 Git 저장소를 만들었다고 하면, 브랜치는 어떻게 될까?

==> Git은 저장소를 만들게되면 'master'라는 이름의 브랜치를 만들게 된다. [ 이 새로운 저장소에 파일 추가 및 추가한 내용을 변경하여 저장 하는 것은 모두 'master'라는 이름의 브랜치를 통해 처리할 수 있음 ]

'master'가 아닌 또 다른 새로운 브랜치를 만들고 이 새로운 브랜치를 사용한다고 선언(checkout)하지 않는 이상, 모든 작업은 'master' 브랜치에서 이루어진다.

---

■ 1-4. 브랜치 만들기

Git 저장소를 만들면 'master'라는 브랜치가 자동 생성되고 이 'master'브랜치 말고 다른 브랜치를 어떻게 생성할까?

==> branch란 명령어로 만들 수 있다. 

$ git branch <branchname>

---

■ 1-5. 브랜치 효과적으로 사용하기

Git에서 작업에 따라 자유롭게 브랜치를 만들 수 있다.

==> 이것을 효과적으로 관리하려면, 먼저 함께 작업할 팀원들과 어떠한 방식으로 브랜치를 만들고 통합할 것인지 미리 정해두는 것이 좋다.

예를들어, 새로운 브랜치를 만들때 브랜치 이름은 어떤 규칙으로 지을 것인지 또는 어떤 상황에서 브랜치를 만들 지, 어느 시점에 통합(Merge)할 것인지 등 규칙을 정하기 나름이다.

---

■ 1-5-1. 대규모 프로젝트에서 사용하는 GitFlow를 통한 효과적인 Git Branch 관리 (feat.배달의 민족)

대규모 프로젝트에서 브랜치를 효과적으로 사용하기 위해선 GitFlow란 전략을 사용한다. GitFlow는 완벽한 방법론이 아닌 각자 팀에 맞는 개발 환경에 따라 변형해 사용하는 게 좋다. 우리는 소규모 프로젝트 이므로 GitFlow 전략에 대해 간단하게 알아보자.

[*GitFlow: Git을 사용한 개발 작업 절차, 프로그램이 아닌 약속, 규칙 같은 개념]

 

이 전략은, 아래의 5가지의 브랜치를 사용한다.

• 항상 유지되는 메인 브랜치들(master, develop)
• 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)

■ 1-5-1-1. Master Branch

제품으로 출시될 수 있는 브랜치 : 배포(Release)이력을 관리하기 위해 사용되며, 즉 배포 가능한 상태만을 관리한다.

■ 1-5-1-2. Develop Branch

다음 출시 버전을 개발하는 브랜치 : 기능 개발을 위한 브랜치들을 병합하기 위해 사용된다. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 'master'브랜치에 병합(merge)한다.

평소에 이 브랜치를 기반으로 개발을 진행한다.

■ 1-5-1-3. Feature Branch

기능을 개발하는 브랜치 : feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 'develop' 브랜치로부터 분기하여 생성한다.

그렇기에 feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 자신의 로컬 저장소에서 관리한다.

개발이 완료되면 'develop'브랜치로 병합(Merge)하여 다른 사람들과 공유한다.

Feature Branch의 작업 순서

1. 'develop' 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.
2. 새로운 기능에 대한 작업을 수행한다.
3. 작업이 끝나면 'develop' 브랜치로 병합(Merge)한다.
4. 더 이상 필요하지 않은 feature 브랜치는 삭제한다.
5. 새로운 기능에 대한 'feature' 브랜치를 중앙 원격 저장소에 올린다.

Feature Branch 이름 정하기

• [feature/기능요약] 형식 추천 EX) feature/login

 

■ 1-5-1-4. Release Branch

이번 출시 버전을 준비하는 브랜치 : 배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다른 배포를 위한 기능 개발을 계속할 수 있다. 명확한 구분이 되어있는 개반 단계를 정의하기에 아주 좋다.

예를들어, 이번주에 버전 1.3 배포를 목표를 한다라는 말을 팀 구성원들과 쉽게 소통하고 합의 할 수 있는 말이다.

Release Branch의 작업 순서

1. 'develop' 브랜치에서 배포할 수 있는 수준의 기능이 모이거나 정해진 일정이 되면, release 브랜치를 분기한다.
   • release 브랜치를 만드는 순간부터 배포 사이클이 시작된다.
   • release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴스와 직접적으로 관련된 작업을 수행한다.
   • 직접적으로 관련된 작업들을 제외하고는 release 브렌치에 새로운 기능을 추가로 병합(merge)하지 않는다.
2. 'release' 브렌치에서 배포 가능한 상태가 된다고 가정하면,
   • 'master' 브렌치에 병합한다. (이때, 병합한 커밋에 Release 버전 태그를 부여한다.)
   • 배포를 준비하는 동안 realease 브렌치가 변경되었을 수 있으므로 배포 완료 후 'develop' 브랜치에도 병합한다.
3. 배포 가능한 수준이 되어 Release Branch를 master Branch에 병합한 후 다음 번 배포를 위한 개발 작업은 'develop' 브랜치에서 계속 진행해 나간다.

Release Branch의 이름 정하기

• [release-*] 형식 추천 [EX] release-1.2

■ 1-5-1-5.  Hotfix Branch

출시 버전에서 발생한 버그를 수정하는 브랜치 : 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, 'master' 브랜치에서 분기하는 브랜치이다. 'develop' 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포 가능한 'master'브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 'master'브랜치에 병합하여 이를 배포해야 하는 것이다.

버그 수정만을 위한 'hotfix' 브랜치를 따로 만들었기 때문에, 다음 배포를 위해 개발하던 작업 내용에 전혀 영향을 주지 않는다.

즉, 'hotfix' 브랜치는 master 브랜치를 부모로 하는 임시 브랜치라고 생각하면 된다.

Hotfix Branch의 작업 순서

1. 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우
   • 'master' 브랜치에서 Hotfix 브랜치를 분기한다. ('hotfix' 브랜치만 master에서 바로 딸 수 있다.)
2.  문제가 되는 부분만을 빠르게 수정한다.
   • 다시 'mater' 브랜치에 병합(merge)하여 이를 안정적으로 다시 배포한다.
   • 새로운 버전 이름으로 태그를 매긴다.
3. Hotfix 브랜치에서의 변경 사항은 'develop' 브랜치에도 병합(merge)한다.

Hotfix Branch의 이름 정하기

• [hotfix-*] 형식 추천 [EX] hotfix-1.2.1

---

■ 1-5-1-6. GitFlow의 전체 흐름

---

■ 1-5-2. 소규모 프로젝트에서 사용하는 Feature Branch Workflow를 통한 효과적인 Git Branch 관리

현재 나는 소규모 프로젝트를 진행하므로 내가 사용할 Git Branch 관리 방법은 Feature Branch Workflow 이다.

• Feature Branch Workflow의 핵심 컨셉은 기능별 브렌치를 만들어서 작업하는 것이다.
• 다수의 팀 구성원이 메인 코드 베이스(master)를 중심으로 해서 안전하게 새로운 기능을 개발 할 수 있다.
• Feature Branch Workflow와 풀 리퀘스트를 결합하면 팀 구성원간에 변경 내용에 대한 소통을 촉진해서 코드 품질을 높일 수 있다.
• 유연성이 큰 협업 방법이다.
• 소규모 인원의 프로젝트에서 사용하는 협업 방법이다.

 

■ 1-5-2-1. Feature Branch Workflow를 사용하기 위해 알아야 하는 기본 개념

• 중앙 원격(remote)저장소 : 여러 명이 같은 프로젝트를 관리하는 데 사용하는 그룹 계정의 중립된 원격 저장소
• 자신의 원격(remote)저장소 : 파일이 GitHub 전용 서버에서 관리되는 원격 저장소
• 로컬(local)저장소 : 내 PC에 파일이 저장되는 개인 전용 저장소, 지역 저장소

■ 1-5-2-2. Feature Branch Workflow의 방법 및 개념

 

1. 프로젝트 참여자는 git clone 명령으로 로컬 저장소를 만든다.

==> git clone 명령으로 중앙 원격 저장소를 복제하여 자신의 로컬 저장소를 만들 수 있다. 프로젝트 참여자는 이 로컬 저장소에서 작ㄱ업을 수행한다.

$ git clone [중앙 remote repository URL]
//git clone 명령은 아래의 명령들을 포함한 작업이다.

//해당 디렉터리를 빈 Git 저장소로 만드는 작업
$ git init
// 현재 작업 중인 Git 저장소에 팀의 중앙 원격 저장소를 추가한다. 이름을 origin으로 짓고 긴 서버 주소(URL) 대신 사용한다.
$ git remote add origin [중앙 remote repository URL]
// 중앙 원격 저장소(origin)의 master 브랜치 데이터를 로컬에 가져오기만 하는 작업
$ git fetch origin master

fetch와 pull의 차이

• fetch: 원격 저장소의 데이터를 로컬에 가져오기만 하기
• pull: 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행
• 즉, 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용한다.
• pull = fetch + merge

2. 현재 로컬에서 작업 중인 branch위치를 표시한다.

중앙 원격 저장소에는 master branch가 있고, 자신의 로컬 저장소에는 master branch와 로그인 기능을 구현할 feature/login branch가 있다고 가정할때, 현재 master branch에서 작업중이라고 하면 아래와 같이 작업 중인 위치를 표시한다.

3. 새로운 기능 개발을 위해 격리된 branch를 만든다.

로컬 저장소에서 branch를 분기하고, 코드를 수정하고, 변경 내용을 커밋한다.

$ git checkout -b [branch name]

# 위의 명령어는 아래의 두 명령어를 합한 것
$ git branch [branch name]
$ git checkout [branch name]

4. 로컬 저장소의 새로운 기능 브랜치를 중앙 원격 저장소에 푸시한다.

•  새로 만든 브랜치(feature/login branch)에 새로운 기능에 대한 내용을 커밋한다.

$ git commit -a -m "Write commit message"

# 위의 명령어는 아래의 두 명령어를 합한 것
$ git add . # 변경된 모든 파일을 스테이징 영역에 추가
$ git add [some-file] # 스테이징 영역에 some-file 추가
$ git commit -m "Write commit message" # local 작업폴더에 history 하나를 쌓는 것

• 커밋을 완료했다면, 내가 작업한 내용을 포함한 브랜치(feature/login branch)를 중앙 저장소에 올린다.
• 이는 로컬 저장소의 백업 역할을 할 뿐만 아니라, 다른 팀 구성원들이 나의 작업 내용과 진도를 확인 할 수도 있어 좋은 습관이라 할 수 있다.

# -u 옵션: 새로운 기능 브랜치와 동일한 이름으로 중앙 원격 저장소의 브랜치로 추가한다.

// 로컬의 기능 브랜치를 중앙 원격 저장소 (origin)에 올린다.
$ git push -u origin feature/login branch

// -u 옵션으로 한 번 연결한 후에는 옵션 없이 아래의 명령만으로 기능 브랜치를 올릴 수 있다.
$ git push -origin feature/login branch
https://gmlwjd9405.github.io/2017/10/27/how-to-collaborate-on-GitHub-1.html

5. 프로젝트 관리자(소규모 팀에서는 모두가 관리자가 될 수 있음)에게 자신의 기여분을 반영해 달라는 풀 리퀘스트를 던진다.

이 단계에서는 프로젝트 관리자(소규모 팀에서는 모두가 관리자가 될 수 있음)에게 자신의 기여분을 중앙 원격 코드 베이스에 반영해 달라고 요청해야 한다. 새로 만든 기능 개발용 브랜치도 중앙 저장소에 올려서 팀 구성원들과 개발 내용에 대한 의견(코드 리뷰 등)을 나눌 수 있다.

• master 브렌치를 손대지 않기 때문에 다른 기능 개발 브랜치를 얼마든지 올려도 된다.
• 이는 일종의 로컬 저장소 백업 역할을 하기도 한다.
• *풀 리퀘스트 : 기능 개발을 끝내고 master에 바로 병합(merge)하는 것이 아니라, 브랜치를 중앙 원격 저장소에 올리고 master에 병합(merge)해달라고 요청하는 것

6. 프로젝트 관리자는 변경 내용을 확인한 후 중앙 원격 코드 베이스에 병합(merge)한다.

이후에는 모든 팀원이 변경한 코드 내용을 확인하고 마지막으로 확인한 팀원이 변경 내용을 중앙 원격 코드 베이스에(merge)하는 작업을 한다.

병합하는 과정은 다음과 같다.

1. GitHub 페이지에서 “Pull requests” 버튼을 누른 후, File changed 탭에서 변경 내용을 확인한다.
2. Conversation 탭으로 이동하여 “Confirm merge”를 하면 중앙 원격 코드 베이스에 병합(merge)된다.
3. 충돌이 일어난 경우는 팀원들고 합의 하에 충돌 내용을 수정한 후 병합을 진행한다.

7. 중앙 원격 저장소와 자신의 로컬 저장소를 동기화하기 위해 로컬 저장소의 branch를 master branch로 이동한다.

// 로컬 저장소의 branch를 master branch로 이동
$ git checkout master

 

8. 중앙 원격 저장소의 코드 베이스에 새로운 커밋이 있다면 다음과 같이 가져온다.

중앙 원격 저장소(origin)의 메인 코드 베이스가 변경되었으므로, 프로젝트 참여하는 모든 개발자가 자신의 로컬 저장소를 동기화해서 최신 상태로 만들어야 한다.

$ git pull origin master

 

9. 새로운 기능을 추가힉 위해서 그 작업에 대한 branch를 생성하여 작업한다.

중앙 원격 저장소와 동기화된 로컬 저장소의 master branch에서 새로운 작업에 대한 branch를 생성하여 작업을 시작한다.

 

---

참고

https://techblog.woowahan.com/2553/

https://gmlwjd9405.github.io/2017/10/27/how-to-collaborate-on-GitHub-1.html