Branch
Git은 개발자들의 협업을 위한 최적의 툴이다.
소프트웨어를 개발할 때에 개발자들은 동일한 소스코드를 함께 공유하고 다루게 된다.
여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없다.
이런 경우, 여러 개발자가 동시에 서로 다른 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치(Branch)' 이다.
브랜치라는 개념은 마치 나무에서 가지를 뻗어 나가는 것과도 비슷하다.
Branch 기능의 장점
- 한 소스코드에서 동시에 다양한 작업을 할 수 있게 해준다.
- 소스코드의 한 시점과 동일한 상태를 만들고, 브랜치를 넘나들며 작업을 수행할 수 있다.
- 각각의 브랜치에서 생긴 변화가 다른 브랜치에 영향을 주지 않고 독립적으로 코딩을 진행할 수 있다.
Branch 종류
master 또는 main 이라는 이름을 가진 통합 브랜치에 뿌리를 두고, 각각의 브랜치가 갈라져 나오고 있다.
이렇게 나누어진 브랜치에서는 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경할 수 있다. 분리된 작업 영역(브랜치)에서 변경된 내용들은 다른 브랜치와 병합(Merge)함으로써 다시 새로운 하나의 브랜치로 모을 수 있다.
통합 브랜치 (Integration Branch)
배포될 소스 코드가 기록되는 브랜치
Github Repository를 생성하게 되면 기본적으로 main(구: master) 브랜치가 생긴다.
해당 프로젝트의 모든 기능이 정상적으로 작동하는 상태의 소스코드가 담겨 있다.
피처 브랜치 (Feature Branch)
기능 추가, 버그 수정과 같이 단위 작업을 위한 브랜치.
통합 브랜치로부터 만들어내며, 피처 브랜치에서 하나의 작업이 완료가 되면 다시 통합 브랜치에 병합하는 방식으로 진행된다.
Topic Branch라 하기도 한다.
Branch 명령어
| 동작 | 명령어 |
|---|---|
| 새로운 브랜치 생성 | $ git branch 새로운 브랜치 이름 |
| 새로운 브랜치 생성 후 해당 브랜치로 전환 | $ git checkout -b 새로운 브랜치 이름 |
| " | $ git switch -c 새로운 브랜치 이름 |
| 브랜치 목록 확인 | $ git branch |
| 브랜치 목록과 각 브랜치의 최근 커밋 확인 | $ git branch -v |
| 브랜치 삭제 | $ git branch -d 삭제할 브랜치 이름 |
| 병합하지 않은 브랜치 강제삭제 | $ git branch -D |
| 브랜치 전환 | $ git switch 브랜치 이름 |
| " | $ git checkout 브랜치 이름 |
| 브랜치 병합master 브랜치로 dev 브랜치를 병합할 때 (master ← dev) | $ git checkout master 후 $ git merge dev |
| 로그에 모든 브랜치를 그래프로 표현 | $ git log --branches --graph --decorate |
| 아직 commit 하지 않은 작업을 스택에 임시로 저장 | $ git stash |
rebase : 커밋의 베이스를 다시 정하고 싶은 경우
squash : 여러 개의 커밋 로그를 하나로 묶고 싶은 경우
revert : 커밋 여러 개의 변경 사항을 취소하고 싶은 경우
—amend : 최근 커밋 메시지를 수정하고 싶은 경우
더 알아보면 좋을 명령어들의 링크
프로젝트 workflow
프로젝트 Remote Repository를 만들었다.
팀원들과 함께 나누어 작업을 하기 위해서 각자의 Remote Repository로 Fork하고
Local에서 작업하기 위해서 git clone 명령어로 Repository를 Local에 가지고 왔다.
fork
git clone '레파지토리 주소'
개발을 진행하는 과정에서는 main 브랜치가 아닌 dev 브랜치를 하나 만들어서 작업을 하는 경우가 많다.
dev 브랜치를 만들어서 해당 브랜치로 이동
git checkout -b dev
또는
git switch -c dev
- Remote Repository 에도 생성한 dev 브랜치를 반영하려면
git push origin dev
생성한 브랜치의 목록과 내가 현재 dev 브랜치에 있는 것이 맞는지 확인
git branch
- 나가기
q
팀 프로젝트에 들어가기 앞서 회의를 통해 하나의 기능을 구현할 때는 ‘feature/기능이름’ 이라는 브랜치를 만들어서 작업하기로 했다.
feature/login 브랜치를 생성하고 이동한다.
git checkout -b feature/login
또는
git switch -c feature/login
feature/login 브랜치에서 로그인 기능이 완성했다.
여기에 소셜 로그인(oauth) 기능을 추가해 보고 싶은데 잘 만들어 놓은 login코드를 건들자니 위험 부담이 있다.
feature/login-oauth 라는 이름으로 feature/login 브랜치에서 파생된 브랜치를 하나 더 만들어서 작업해본다.
git checkout -b feature/login-oauth
또는
git switch -c feature/login-oauth
oauth 기능을 잘 구현했다.
feature/login-oauth 에 있는 코드를 feature/login 브랜치로 병합해보자
-
feature/login 브랜치로 이동
git checkout feature/login
또는
git switch feature/login -
feature/login-oauth 의 내용을 현재위치 브랜치로 병합
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 방식으로 병합되었을 것이다.
- merge와 rebase의 차이점
rebase원리가 fast-forward와도 같다.
로컬의 작업한 내용을 Remote Repository 에 업로드하기 위해 push한다.
feature/login 브랜치를 업로드
git push origin feature/login
feature/login 브랜치의 변경 사항을 dev 브랜치에 적용하고 싶다.
Github의 Pull Request 기능을 활용해 dev 브랜치로의 반영을 요청할 수 있다.
리뷰가 끝난 코드는 브라우저에서도 dev 브랜치로 merge 할 수 있다.
프로젝트를 진행하시는 전체 흐름
만약 작업하던 중간에 Remote upstream 에 업데이트가 생긴다면 Local 로 pull해 받아주어야 한다.
메타인지
🎯 오늘의 학습목표
- Git 브랜치의 개념을 이해할 수 있다
- Git 으로 협업하며 브랜치를 나누는 이유를 이해할 수 있다.
- Git 으로 프로젝트를 관리하며 브랜치를 생성, 전환, 병합할 수 있다.
😎 학습할 내용 중에 알고 있는 것
Github, Git 환경설정
✏️ 오늘 새롭게 학습한 것
Git Branch
🧷 오늘 학습한 내용 중 아직 이해되지 않은 부분
commit과 pull request
💡 이해되지 않은 내용을 보완하기 위해 무엇을 할까
프로젝트 제작과정 예시를 찾아본다.
