[데브코스 TIL] Day 5 - Git branch 전략 - 웹 풀 사이클 데브코스 TIL

김진환·2023년 11월 20일

TIL 교육생 데브코스 수강후기

데브코스 웹 풀스택 과정 1기

목록 보기

6/15

'23.11.20(월) 웹 풀 사이클 데브코스 TIL

Git branch와 merge를 이용해 협업하기

이전 시간에 Git branch의 개념에 대해 간략하게 다루었다.

그럼 branch는 어느 시점에 나누어야 하는가?

기능 개발 - 프로젝트의 새 기능 구현
-> feature/login, feature/select-product 등
출시 준비 - release-1.3
-> 출시를 위한 브랜치와 개발을 위한 브랜치 구분
긴급 수정 - hotfix-1.2.1
-> 배포 후 버그나 수정사항이 생겨 긴급수정하는 경우

위와 같은 시점에서 branch를 나누게 되고, 작업이 종료되면 일반적으로 분리된 branch를 main branch에 병합한 뒤 해당 branch를 삭제한다.

이 병합(merge)과정에서 여러 문제가 발생할 가능성이 있다.

같은 파일의 같은 위치를 다르게 변경해 merge하는 경우
-> 파일 충돌이 직접적으로 일어나는 경우
1번의 경우에 해당되지 않지만 잠재적인 충돌 가능성이 존재하는 경우
-> 변수명이 공유되거나, 특정 값을 변화하는 코드 등 논리적인 오류가 발생할 수 있는 경우

위와 같은 상황을 방지하려면 적절한 전략이 필요한데,

이를 Git Branch 전략이라고 한다.

Git Branch 전략

git branch 전략은 크게 두 가지로 구분한다.

사진의 예시에서 A를 main branch, B를 추가기능 구현 branch라고 가정해보자.

Fast-Forward 전략
main 브랜치가 존재하는 상황에서 추가기능 B 브랜치를 만들어 작업 후, A 브랜치 바로 뒤에 병합하는 방식
-> main 브랜치에는 B 브랜치 생성 이후 커밋이 없는 상태에서 그대로 이어진다.

Fast-Forward는 "빨리감기" 라는 뜻으로
직접적인 의미 보다는 빠르게, 연결해서 라는 정도의 키워드에서 따온 네이밍이지 않을까 예상한다.

3-way 전략

main 브랜치에서 B 브랜치를 생성하고, main과 B 브랜치 둘 다 커밋을 이어나간 뒤
병합하는 방식
이 같은 경우는 main 브랜치가 아니라 추가적으로 더 많은 브랜치로 한 번에 병렬적으로 작업하는 형태도 해당된다.

Branch는 협업이 중점인 기능이기 때문에 일반적으로 3-way 전략을 중심으로 사용한다.

Fast-Forward 전략은 뒤에 계속 이어붙이는 방식이기 때문에 충돌 리스크가 적고,
3-way 전략은 커밋 순서를 조정할 수 있는 구조이기 때문에 충돌 리스크가 상대적으로 크다.

Merge

두 가지 전략을 사용하기 위해 Merge(병합)라는 개념을 언급했다.
실제로 깃허브에서 merge 하는 방법에 대해서 알아보자.

merge의 과정은 다음과 같다.

main 브랜치 보호
pull request
로컬 환경에 동기화

1. main 브랜치 보호

remote repo에서 branch를 생성하면 main 브랜치에 다음과 같은 경고문이 뜬다.

다른 사람 혹은 내가 main branch에 커밋을 push하게 되면 이는 이전 상태로 되돌릴 수 없기 때문에 main branch로의 push나 삭제 등을 방지하는 조치가 필요하다.

보안적인 요소 뿐만 아니라 실수를 방지하고자 하는 목적도 포함되어있다.

2. pull request

적절히 설정을 수정해 주면 깃허브 repo에서 merge하고자 하는 브랜치에서 pull request를 보낼 수 있다.

pull request를 보낼 때는

주요 구현 내용과 해당 구현 과정 내 이슈를 구분해 작성해 주는 것이 좋다.

pull request를 보내면, 깃허브에서 자동으로 파일 충돌을 검사하고 결과를 보여준다.

충돌 검사를 통과한 모습이다.
Merge 권한을 가진 멤버가 Merge pull request 버튼을 누르면

pull request가 닫히고 merge된다. 이 때 merge커밋이 추가된다.
특이사항이 없다면 작업이 끝난 branch는 delete한다.