[Git] Git 기본 용어와 Git-flow

Git... 너무 어려워...

사실 이 전에는 main 브랜치에서 모든 작업을 진행하고, 단순히 버전을 관리하고 백업을 쌓아두는 용도로만 썼었는데, 이번에 우아한 테크캠프를 하면서 처음으로 Git을 제대로 사용하고있다. 많이 부끄럽지만 지금이라도 알게 된 게 어디야..! 이제 익숙해지기 위해 용어 정리를 먼저 해봤다.

 

fork / clone

fork: 다른 사람의 repository에서 내가 어떤 부분을 수정하거나 추가 feature를 넣고 싶을 때, 내 github repository로 그대로 복제하는 기능. fork한 저장소는 원래의 저장소(upstream)와 연결되어 있어 해당 repository에 어떠한 변화가 생기면 fetch나 rebase등을 통해 변경사항을 내가 fork한 저장소로 가져올 수 있다. 반대로 내가 fork받은 저장소에서 원래의 저장소로 변경사항을 반영시키고 싶을 때에는 Pull Request라는 요청을 보내게 된다. 그 다음 upstream의 관리자가 해당 pull request를 보고 승인 한 후 merge의 과정을 거치면 나의 코드(commit들이)가 upstream에 반영이 된다.

clone: 특정 저장소(repository)를 내 컴퓨터(local)에 복사해서 새로운 저장소를 만든다. clone한 원본 저장소를 remote 저장소로 갖고있다. 원본 저장소의 권한이 나에게 있으면 변경사항을 바로 push 할 수 있다.

 

upstream / origin / local / remote

upstream: 실제 서비스가 돌아가는 저장소(repository)
origin: upstream에서 fork를 받은 나의 저장소
local: origin을 clone받아 실제로 내가 작업하고 있는 저장소

remote: 변경 이력을 공유하고 받아 올 원격 저장소

git remote add
내 local 저장소의 remote repository를 변경 혹은 추가할 때 사용하는 저장소

$git remote add origin https://github.com/@@/repo.git
//해당 저장소의 origin을 @@.git으로 설정하겠음! (처음 기본으로 clone한 원본 저장소가 origin으로 자동 설정 되어 있음!)

$git remote add upstream https://github.com/~~~/repo.git
//해당 저장소의 upstream을 ~~.git으로 설정하겠음!

 

git remote show 
나의 remote 저장소들을 확인할 때 사용하는 명령어

$git remote show origin
$git remote show upstream
//등록이 안되어있으면 아무것도 출력되지 않음

 

fetch / pull / merge / rebase

원격 저장소가 연결되어 있다고 해서 자동으로 변경 내역이 동기화 되지는 않는다. 원격 저장소에서 변경된 이력을 가져오는 작업이 필요한데, 이때 fetch 혹은 pull을 사용한다.

fetch: remote 저장소에서 변경된 이력을 가져만오기 (별도의 병합 진행 필요)

$git fetch upstream main
// upstream 저장소의 main 브랜치의 이력을 가져온다

$git fetch origin main
// origin 저장소의 main 브랜치의 이력을 가져온다

pull: remote 저장소에서 변경된 이력을 가져오기 + 병합 (fetch + merge)

$git pull upstream main
// upstream 저장소의 main브랜치 이력을 가져와 병합한다

$git pull origin main
// origin 저장소의 main브랜치 이력을 가져와 병합한다

merge: remote 저장소에서 가져온 변경된 이력을 내 브랜치로 병합하기

$git checkout feature // feature 브랜치로 이동 후
$git merge main // main branch의 작업 내용을 가져와 병합하기

rebase: remote 저장소에서 가져온 변경된 이력을 내 브랜치의 base로 옮기기

$git checkout feature // feature 브랜치로 이동 후
$git rebase main // main branch의 내용으로 rebase 시키기

merge vs rebase

merge와 rebase는 둘 다 fetch 후 코드를 병합할 때 사용한다

이 둘은 과연 어떤 차이가 있을까?

 

출처: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

merge는 병합시킬 branch를 그대로 가져와 내 branch에 병합하면서 그 결과물인 merge branch를 생성한다.

rebase는 병합시킬 branch의 커밋 내역을 가져와서 나의 commit 앞에 넣는다. (내가 작업하던 내용을 main branch의 커밋들 이후에 진행되고 있는 것 처럼 만든다) 하지만 내가 변경중이던 내역들은 commit 그대로가 아닌 새로운 커밋으로 생성된다.

 이 둘의 장 단점을 살펴보면 다음과 같다.

	merge	rebase
history	histor가 복잡하게 쌓인다 (단점)	history가 단순하다 (장점)
branch	존재하는 브랜치들에 변화를 주지 않는다 (장점)	존재하는 브랜치에 변화를 주기 때문에 여럿이 사용하는 public branch에 사용되어서는 안된다. (단점)

 

Git flow

Git-flow란 Git을 활용한 개발 작업 절차를 말한다. 우선 5가지 종류의 브랜치가 있는데, 메인 브랜치들(main, develop)과 보조 브랜치들(feature, release, hotfix)가 있다.

• main: 제품으로 출시 될 수 있는 브랜치 (예전에는 master branch로 많이 불렸다)
• develop: 다음 출시 버전을 개발하는 브랜치
• feature: 특정한 기능을 개발하는 브랜치
• release: 이번 출시 버전을 준비하는 브랜치 (해당 브랜치에서 QA등이 이루어지고 문제가 없으면 main으로 merg)
• hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

일반적으로 우테캠에서는 아래와 같은 순서로 Git을 다루고 있다.

1. 팀 미션 repository를 생성한다. (upstream)
2. 내 계정에서 fork를 받아온다. (origin)
3. 내 컴퓨터로 저장소를 clone 한다. (local)
4. 내 local에서 feature 단위로 브랜치를 만들어 열심히 작업을 진행한다
5. 작업 내용을 origin으로 push 하기 전에 upstream의 작업 내용을 fetch 받아 merge / rebase 한다.
   5 - 1. 작업 중 conflict가 일어나면 충돌 처리를 한다
6. origin 으로 나의 작업 내용을 push 한다.
7. github에서 upstream으로 pull request를 날린다.
   7 - 1. 동료의 PR Review 후 작업물을 upstream에 merge 한다.
8. 4 ~ 7 과정 반복

5번의 과정이 제대로 이루어 지지 않는다면 PR을 할 때 충돌이 일어나서 approve가 되지 않으니 동료들이 upstream에 새로운 기능이 merge 되었다고 하면 그 때 그 때 fetch를 받고있다!

 

이번 우아한 테크캠프에서 가장 크게 배우고 있는 것 중 하나인 Git의 용어와 Git-Flow를 정리해봤다. 해도해도 어려운게 rebase 하는 것이더라... 다음에는 조금 더 익숙해져서 다양한 커맨드를 다룰 수 있었으면 좋겠다 🙂 !!

 

참고

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

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Merging vs. Rebasing | Atlassian Git Tutorial

https://www.youtube.com/watch?v=MIGliPrUMGE