Achievement Goals

Git 브랜치의 개념을 이해할 수 있다.
Git 으로 협업하며 브랜치를 나누는 이유를 이해할 수 있다.
Git 으로 프로젝트를 관리하며 브랜치를 생성, 전환, 병합할 수 있다.

🍞 브랜치(branch)

브랜치란 ?
이미 짜놓은 코드를 독립적으로 따로 빼놓은 개념이라고 볼 수 있다.
이 브랜치가 왜 좋은가 하면, 만약 어떤 길고긴 코드를 혼자서 수정 작업하고 싶은데 잘못건드렸다간 기존에 해놓은 작업을 망칠 수 있고 그로인해 멘붕이오고 살기싫고 스트레스가 오고 탈모가 온다. (응?)
아무튼 브랜치는 독립적으로 따로 저장이 되기때문에 기존의 코드는 그대로 둔 채, 같은 코드를 통째로 복사한것과 같으므로 코드변경 우려 없이 맘껏 개발을 할 수 있다. 이러한 기능으로 여러가지 작업을 동시에 진행할 수 있다.

정리를 해보자면,

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

그동안 익히 알고있는 브랜치로 master/main 브랜치가 있었는데 이것은 브랜치의 뿌리라고 할 수 있다.
여태 이 두가지만 있는 줄 알았는데 hotfix, release, develop, feature 등 다양한 브랜치를 만들 수 있다.

서로다른 브랜치에서 작업을 한 후 변경된 내용은 다른 브랜치와 병합(merge)
할 수 있다.

예를들어, 자신이 어떠한 독립적인 작업을 완료했을때 통합 브랜치에 병합시킨다. 또 다른사람이 맡은 어떠한 작업을 그 통합브랜치에 병합하여 변경사항을 저장시킨다.
이렇게 작업을 진행할 경우 어떠한 문제가 터졌을때 작업단위로 나누었기 떄문에 문제의 원인이 되는 부분을 빨리 잡을 수 있다.

🍞 브랜치 종류

🥪 통합 브랜치(Integration Branch)

main / master 같은, 처음 레포지토리 생성 시 만들어지는 브랜치.
브랜치의 뿌리가 되는 부분이라고 생각하면 된다.
여기에는 배포될 소스 코드가 기록되며 해당 프로젝트의 모든 기능이 정상적으로 작동하는 상태의 소스코드가 담겨져 있다.

🥪 피처 브랜치(Feature branch)

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

🍞 브랜치 명령어 모음zip

🥪 새로운 브랜치 생성
$ git branch 새로운 브랜치 이름
🥪 새로운 브랜치 생성 후 해당 브랜치로 전환
$ git checkout -b 새로운 브랜치 이름
$ git switch -c 새로운 브랜치 이름
🥪 브랜치 전환
$ git checkout 브랜치 이름
$ git switch 브랜치 이름
🥪 브랜치 목록 확인
$ git branch
🥪 브랜치 목록과 각 브랜치의 최근 커밋 확인
$ git branch -v
🥪 브랜치 삭제
$ git branch -d 삭제할 브랜치 이름
$ git branch -D 해당 명령어는 병합하지 않은 브랜치를 강제 삭제하는 방법입니다.
🥪 브랜치 병합
master 브랜치로 dev 브랜치를 병합할 때 (master ← dev)
$ git checkout master
$ git merge dev
🥪 로그에 모든 브랜치를 그래프로 표현
$ git log --branches --graph --decorate
🥪 아직 commit 하지 않은 작업을 스택에 임시로 저장
$ git stash

🍞 프로젝트 git workflow

실질적으로 팀원들과 프로젝트를 할때의 프로시저는 어떻게 될까?
차근차근 살펴보도록 하겠다.

1. fork + git clone 으로 가져오기
스프린트하면서 맨날 했던짓. 리모트에 있던 레포지토리를 내 레포지토리로 가져오는것. 이하설명 생략.ㅋㅎㅋㅎ

2. main / master 브랜치에 dev (HEAD) 브랜치생성
main 브랜치가 루트가 되는것은 맞지만 보통 dev 브랜치를 새로 생성하여 그곳이서부터 시작한다.

git checkout -b dev 또는 git switch -c dev
git push origin dev 

이때 HEAD 는 현재 위치한 커밋을 나타낸다.
그리고, remote repository 에도 내가 새로 생성한 브랜치를 적용시키기 위해 origin 에 dev 를 푸쉬해주는 명령어를 사용한다.

3. 브랜치생성 확인하기
브랜치가 생성여부와 현재위치가 새로생성한 브랜치에 위치해있는지 확인하는 명령어이다.

git branch

확인 후 나가고싶다면 q를 눌러 종료한다.

4. 각 기능별 브랜치 생성하기
팀원들과 회의 후 어떠한 기능을 넣기로 결정했다.
dev 브랜치에 그냥 넣는것이 아닌, 작업분할을 위해 "feature/기능" 브랜치를 만들어 해당되는 작업물을 넣는다.
만약 로그인기능을 넣고싶다면 feature/login 이라는 브랜치를 생성한다.

git checkout -b feature/login 또는 git switch -c feature/login

해당명령어를 작성하여 생성과 동시에 그 브랜치로 이동하도록 한다.
또한 기존 로그인 기능에 OAuth 소셜로그인 기능을 추가하고 싶다면 feature/login 브랜치에 그대로 작성하는것보다 새로운 브랜치 feature/login-oauth 브랜치를 생성하도록 한다. 기존의 잘 만들어놓은 로그인 기능코드가 잘못될 가능성이 있기 때문이다.
단, feature/login 에서 파생된 브랜치이기 때문에 위치를 잘 확인한 후 브랜치를 생성한다!

git checkout -b feature/login-oauth 또는 git switch -c feature/login-oauth 

5. 완성된 기능 한 브랜치로 병합하기
로그인 기능과 소셜로그인 OAuth 코드가 완벽히 구동되는것을 확인 후 두 브랜치를 하나로 합치기로 한다.
그러기위해 OAuth 의 형님격인 feature/login 으로 이동한다.
(합칠 브랜치의 형님격으로 이동.여기서 HEAD 는 feature/login가 되것쥬?)
이동 후 파생된 feature/login-oauth 와 병합하기 위해 merge 시킨다.

 git checkout(switch) feature/login // 형님브랜치로 이동
 git merge feature/login-oauth // 형님브랜치와 oauth 브랜치와 병합

자동적으로 fast-forward 방식으로 병합이 이뤄진다.

🧐 fast-forward 란?

rebase 방식으로, 별도의 커밋을 생성하지 않고 feature/login 브랜치가 가리키는 커밋을 feature/login-oauth 가 생성한 커밋으로 바꾸는 작업을 말한다.
만약 feature/login를 커밋한 상태에서 merge 를 했다면 이는 merge commit 방식으로 병합이 되었을 것이다.
merge
변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해진다.
rebase
말 그대로 branch base를 이동시킨다는 뜻으로, 머지처럼 브랜치 통합을 목적으로 하지만, 특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능을 한다.

git rebase main feature/login

• merge 와 rebase 방식의 차이
  

6. 로컬에 작업된 내용 push 하기

작업이 모두 완료되면 Remote Repository 에 push 하는 작업을 한다.

 git push origin feature/login

7. dev 브랜치에 적용하기
Github의 Pull Request 기능을 활용해 dev 브랜치로의 반영을 요청할 수 있다. 리뷰가 끝난 코드는 브라우저에서도 dev 브랜치로 merge 할 수 있다.

create pull request 버튼 눌러 merge
(예시로 든 사진이라 버튼이 blk 처리되있음. 양해부탁.)

🍞 전체적인 브랜치흐름 보기

다음은 앞에서 다룬 전체적인 프로시저를 도식화 해놓은 그림이다.

프로젝트를 올리기 위해 제일처음 로컬에 새로운 브랜치를 생성하고, 작업이 끝나면 리모트에 푸시를 해준다. 이때 제일 뿌리가되는 리모트인, Project Upstream Repository 에도 반영되어야 하므로(merge) pull request 해주는것을 잊으면 안된다.
만약 Project Upstream Repository에 변경사항이 생긴다면 로컬에 다시 pull 해주어야 한다.

• git extension : git graph
  

git graph 누르면 현재있는 브랜치, HEAD 등 쉽게 볼수있다.