7월 2째주 - github강의(브랜치)

23/07/12 실시간 강의

 

개강 첫 날엔 OT를 진행하고 2일차부터 깃허브 강의를 시작했다.

첫 날은 로컬저장소 개념인 git을 배웠는데 이 부분은 예전에 다 정리해둬서 생략했다.

오늘은 브랜치 관련해서 배웠는데 프로젝트를 하면서 예전에 배웠지만 개념이 확실하지는 않아 제대로 정리해보려 한다.

 

개발할 때 브랜치를 나누는 이유

• 안전성을 위해
• 개발용 브랜치, 테스트용 브랜치 등등
• main(deploy)을 배포용 버전으로 사용
• develop 브랜치에서 개발을 다 마치면 main에 반영

 

브랜치 merge, rebase, pr 등에 대해 배웠는데 merge는 프로젝트하면서 자주 써서 잘 아는내용이라 기본적인 내용은 생략하고 fast-forward, rebase, pr에 대해 정리해보려한다. 

 

fast-forward란?

위와 같은 상태에서 main 브랜치에서 develop 브랜치 merge를 시도하면 어떻게 될까?

merge를 시도하면 다음과 같이 Fast-forward라는 문구가 뜬다.

log를 봤더니 merge를 했음에도 새로운 커밋이 생기지 않았다.

즉, 새로운 커밋이 생기는 것이 아니라 그냥 main 브랜치에 develop 브랜치의 commit 기록이 병합되면서 아래와 같은 형태로 커밋 기록이 만들어지는 것을 fast-forward라고 한다.

 

만약 첫 사진처럼 줄기가 나눠진 형태로 커밋 기록을 남기고 싶으면 아래의 명령어를 입력하면 된다.

git merge develop --no-ff

 

rebase란?

rebase는 특정 브랜치를 base로 두고 커밋 이력을 정렬하겠다는 명령어다.

위 그림과과 같이 브랜치가 나뉘어져있을 때, main에서 rebase develop을 실행할 경우 아래처럼 develop의 커밋 이력을 base로 해서 거기에 이어서 main의 커밋 이력이 정렬되게 된다.

즉 merge(non fast-forward)와 같이 줄기가 나뉘지 않고 아래처럼 하나의 줄기로 커밋 이력이 정렬되게 된다.

# rebase는 정확히 말하면 병합을 위한 것이 아니라, 커밋 히스토리를 정렬하기 위한 명령어이다. 이미 병합이 된 브랜치가 있더라도, 거기서 rebase 를 하면 커밋 히스토리를 다시 정렬할 수 있다.

 

# rebase는 커밋 이력을 단순히 관리하고 싶을 때 사용하는 명령어이고, merge 는 변경 이력을 모두 남기고 싶을 때 사용하는 명령어다. 실제로는 커밋 이력을 남기는 것이 굉장히 중요하기 때문에, rebase 는 fork시에 원본 프로젝트에 맞게 (동기화해서) 변경 이력을 관리하고자 하는 특수한 상황에서만 사용하고, 보통은 merge 만을 사용한다.

 

 

PR(Pull Request)란?

PR이란 내 담당 브랜치에서 작업이 완료되었으니 이 브랜치의 코드를 가져가서 병합해줘"라고 요청을 보내는 것이다.

현업에서의 git 관리 방식

main 브랜치: 사용자가 이용할 서비스의 코드가 담기는 브랜치(즉, 해당 브랜치에 있는 코드가 사용자에게 배포됨)

 

develop 브랜치: 사용자에게 서비스를 배포하기 이전에, 모든 기능들이 통합되어서 테스트를 진행하는 브랜치. 테스트가 완료되면 main 브랜치에 코드를 통합해서, 실제로 사용자가 이용하는 서비스에 코드가 반영(보통은 테스트용 브랜치가 따로 존재)

 

feature ~ 브랜치: 서비스의 기능을 분할해서, 기능 하나를 구현하는 브랜치. 여기서 하나의 기능 구현이 완료되면, develop 브랜치로 내 코드를 통합해달라고 요청을 보냄

 

주니어 개발자가 그냥 마구잡이로 develop 브랜치에 코드를 merge 해버리면 어떻게 될까?

코드가 비효율적으로 작성되었는데도, 오류가 발생하는 코드인데도, 이 코드를 서비스에 반영해버리게 되면 큰 문제가 발생

→ 따라서 개발자가 작성한 코드를 merge 하기 이전에 ‘병합해주세요’ 라는 요청을 보내고, 시니어 개발자 혹은 동료들이 그 코드를 보고 ‘코드 리뷰’ 를 진행하면서, 더 효율적으로 작성할 수 없는지, 오류가 발생하는 코드는 아닌지를 검사함. 검사가 완료되면, 그제서야 관리자가 병합 요청을 승인하고, 해당 기능이 develop 브랜치에 반영됨.

 

즉, pr을 하는 이유

1. 내가 작성한 코드가 바로 merge될 경우 발생할 수 있는 문제를 미리 방지

2. 현재 코드에 대한 코드 리뷰 진행

3. 프로젝트에 대한 진행 상황 관리

 

 

보통 pr을 작성할 때는 다음과 같은 내용으로 작성한다.

- 현재 PR 요약/개요

- 코드 변경 이유 (작성 이유)

- 관련 스크린샷

- 테스트 내용

- 리뷰 관련 요청사항

 

pr을 하고나서 merge 후 브랜치를 삭제하고 git pull origin main을 통해 로컬저장소의 코드도 바꿔주었는데, 우리 컴퓨터는 브랜치 삭제를 인식하지 못한다.

(origin/~: github쪽 브랜치. 나머지가 로컬 브랜치)

git fetch --prune

이 명령어를 입력하면, 우리 컴퓨터가 github 상에서 해당 브랜치들이 삭제되었음을 인식함

그리고,

git branch -D 로컬브랜치이름

이 작업을 통해 로컬 브랜치들을 삭제해준다(삭제하냐 안하냐는 선택이지만 강사님은 pr가 merge된 후에는 지우면서 진행한다고 하심)

 

 

issue&milestone이란?

issue는 github 에서 자주 사용되는 기능인데 어떻게 사용할지는 git 전략에 따라 조금씩 달라지기도 하지만, 보통 앞으로 구현할 기능 / 버그 fix 등의 할일을 정리해놓는 용도로 사용한다.

 

milestone이란 issue의 집합을 말함. milestone을 활용하면 진행상황을 관리할 수 있다. 작업이 완료된 이슈가 얼마나 있는지 %로 나타내줘 쉽게 진행도를 알 수 있다.

 

 

깃허브에 대한 상세한 강의를 들었는데, 나는 프로젝트를 진행할 때 merge이외엔 다 써보지 않았던 것들이라 생각보다 어려웠다. 어느정도 이해는 된 것 같은데 계속 복습하고 실제 개발할 때 써보면서 익숙해져야할 것 같다.