웹 풀사이클 데브코스 TIL 5일차 - branch, 깃 플로우, merge

git 브랜치 이름 규칙

메인 브랜치 -> 사용자들이 사용할 수 있는 완성된 버전을 가지고 있음.

 

기능 개발 : 기능을 개발하기 위한 브랜치, feature/login

출시 준비 : 출시를 위한 브랜치, release-1.3

긴급 수정 : hotfix-1.2.1

 

 

브랜치 삭제하기

git branch -d dev

 

 원격 저장소의 브랜치 확인

git branch -r

: 원격 저장소의 브랜치 확인

 

git branch <브랜치명> 으로 브랜치를 만드는 것만으로는 github에 올라가있지 않다. 

따라서 원격에 올려주는 과정이 필요하다. 

 

원격저장소의 branch 상태와 다르다면 git fetch -p를 통해서 동기화해주면 된다.

브랜치 github에 올리기

1. 브랜치를 따로 올리기

브랜치가 만들어진 상태에서 push를 해보자. 

이처럼 push가 바로 되지 않는다.

git push <repository 별칭> <브랜치명>

 

feature/main-page를 올리고 싶은 경우 git push origin feature/main-page를 하면 브랜치가 올라간다.

 

2. push를 하면서 올리기

git push --set-upstream <레포지토리 별칭> <브랜치명>

git push -u <레포지토리 별칭> <브랜치명>

add 와 commit 후 첫 push를 할 때, 위 두가지 방법 중 하나를 사용하면 좀 더 간편하다.

브랜치 전략(깃 플로우)

깃을 활용한 업무 흐름은 어떻게 짤 수 있을까?

1. fast forward 

A 브랜치에서 B브랜치를 생성 후, A브랜치에서는 추가 구현을 하지 않고 B브랜치에서 작업 후 B와 A를 합치는 전략이다.

어느정도의 복잡한 프로젝트는에서는 자주 쓰이지 않는 방법이다.

해당 그림은master가 나뉘어진 이후 새로운 변경사항이 없는 것을 볼 수 있다. 

따라서 master에서 merge한다면 c4는 c2에서 기반한 브랜치이므로 딱히 merge과정 없이 최근 커밋인 c4로 이동한다. 이런 merge방식을 fast-forward라고 부른다.

 

. 3-way 전략 (가장 많이 쓰임)

A브랜치에서 B브랜치를 생성후, A브랜치와 B브랜치 모두에서 추가 구현을 한 뒤 서로 비교하며 바뀐것을 정리하여 합치는 전략이다. 

 

1. 두가지로 나뉜 브랜치

2. 즉, 첫 합병은 fast forward방법이다.

3. 그 후 비교하며 아래 브랜치를 합친다. 3-way방법으로 합친다.

급하게 hotfix를 처리하고 master는 hotfix의 변경사항을 머지한 상태이다. 즉 2번 사진의 상태이다. 그리고 iss53브랜치와 master 공통 조상인 c2를 이용하여  3-way Merge를 진행한다. 

이후 iss53브랜치를 삭제하고 이슈를 완료처리한다.

 

main 브랜치 보호하기

add branch protection을 통해 원하는 설정을 할 수 있다.

pull request를 해야하는지 몇개의 승인을 받아야 할 수 있는지 등을 설정할 수 있다.

feature/header 브랜치를 pull request를 하고 싶은 경우 해당 브랜치로 들어가 contribute 버튼을 누르면 가능하다. 

description은 markdown이 가능하다. (description은 주요 구현내용, 발생한 이슈를 적어주는 것이 좋다.)

 

병합이란?

브랜치를 생성한다는 것은 "협업"을 위한 것이다. 

 

main 브랜치 보호

추가 브랜치에서 main 브랜치 병합시켜줘! = pull request

충돌 일어나나? 자동으로 확인을 해줌 =  pr 메세지

 

 

git 동기화하기

github에서 머지 후 버튼을 눌러 브랜치를 삭제했다.

그 후 로컬에서 브랜치를 찍어보면 여전히 feature/header가 있는 것을 볼 수 있다.

git fetch -p

언뜻 보면 삭제가 된 것 같다. 하지만 branch를 찍어본다면? 

이렇기 때문에 main으로 넘어가서 삭제해준다.

삭제되었다.

 

정리: 

 

github에서 브랜치를 삭제했기 때문에 fetch를 통해 연결된 브랜치 목록을 동기화 해준다. 그 후 로컬에서 브랜치를 찍어보면 삭제된 브랜치가 남아있음을 볼 수 있다. 따라서 main브랜치로 이동하고, merge된 내역을 받아온 뒤 삭제된 브랜치를 명령어를 통해 삭제해주는 것이다. 

 

마지막으로 merge되지 않은 브랜치는 Merge 하지 않은 커밋을 담고 있기 때문에 삭제가 되지 않는다. merge된 브랜치인지 아닌지를 확인하는 방법은 다음과 같다.

$ git branch --merged

- merge된 브랜치 확인

$ git branch --no-merged

- merge되지 않은 브랜치 확인

 

merge되지 않은 브랜치를 삭제하기 위한 명령어

$ git branch -D testing

브랜치 받아오기

내가 만들지 않은 브랜치, github에 있는 별칭이 origin이고 브랜치명이 feature/1인 브랜치를 받아와보자!

git checkout -t origin/feature/1

 

출처: 데브코스 강의, https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EA%B4%80%EB%A6%AC

Git - 브랜치 관리