01. Branch 기본

1) branch 의 개념과 활용법

brach: 버전 관리의 분기점을 만드는 기능

• 현재 작업 중인 내용을 유지하면서 파일과 커밋 기록을 별도로 관리하고자 할 때, 브랜치를 분기한다.
• 브랜치를 분기하면, 그때부터는 파일과 커밋 기록이 이전 브랜치와의 파일과 커밋 기록이 완전히 별도로 관리된다.
• 브랜치는 게속 추가할 수 있는데, 항상 원본 브랜치가 있어야 분기할 수 있다.

2) branch 생성, 전환, 삭제

브랜치 생성

git switch [새 브랜치명]

브랜치 생성한 뒤 생성된 브랜치로 이동

git switch -c [새 브랜치 명]

브랜치 목록 확인

git branch --list

브랜치 삭제

git branch -D [브랜치명]

🎈 2019년까지는 git checkout 이라는 명령어를 사용했으나, git 이 업데이트되면서 git switch 라는 명령어가 만들어졌고, 이를 사용하도록 권장하고 있다.

• git checkout -b 라는 명령어와 git switch -c 라는 명령어가 동일하고,
• 그냥 git checkout 과 git switch 라는 명령어가 동일합니다.

02. Branch 활용하기: merge

1) branch 병합하기 (git merge)

git merge: 서로 다른 branch의 작업 내용을 하나의 branch로 통합하기 위한 명령어

git merge [브랜치명]

합치길 원하는 브랜치로 이동 후에 합칠 브랜치를 입력한다.
예시) main 브랜치에 develop 브랜치를 합치고 싶다.

git merge develop

위 명령어를 입력하면 main에는 없고 develop에만 있던 수정 사항이 main에 통합진다.

그래프로 커밋 기록 확인하기

git log --graph --decorate --oneline

2) merge 시의 merge conflict 해결하기

위와 같이 merge한 상황에서 특정 파일에 대한 main의 수정사항과 develop의 수정 사항 기록이 다르다면 오류가 난다. 그것을 merge conflict 라고 한다.
따라서, merge conflict 는 다른 두 파일을 어떻게 합쳐야할지를 결정할 수 없을 때 발생한다.

해결 방법

1. Accept Current Change: 현재 우리가 있는 main 브랜치의 내용을 따른다.
2. Accept Incoming Change: 병합하는 develop 브랜치의 내용을 따른다.
3. Accept Both Changes: 두 브랜치 내용 모두를 담는다.
4. 직접 코드 수정하기

원하는 작업으로 수정 후에 커밋을 해주면 해결된다.

3) fast-forward 이해하기

fast-forward: merge했을 때, 새로운 커밋이 생기는 것이 아니라, 그냥 main 브랜치에 develop 브랜치의 commit 기록이 병합되는 것

만약 줄기가 나눠진 형태로 커밋 기록을 남기고 싶다면, 아래와 같이 --no-ff를 붙여서 merge 명령어를 입력하면 된다. (non fast forward의 약자)

git merge [develop] --no-ff

😭잘 이해가 안간다....

03. Branch 활용하기: rebase

1) git rebase 활용하기

rebase: 특정 브랜치를 base (기준) 로 놓고, 커밋 이력을 정렬하는 명령어

git rebase [develop]

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

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

2) rebase 시의 merge conflict 해결하기

rebase 시에도 merge conflict 가 발생할 수 있는데, 해결 방식이 조금 다르다.

git add .
git rebase --continue

merge시에 merge conflict가 났을 때는 파일을 수정해준 후에 바로 add -> commit을 진행하면 해결되었지만
rebase merge conflict는 add를 진행한 후에 commit 대신, git rebase --continue 를 진행한다.

git rebase --abort

만약 merge conflict 가 발생한 상황에서 rebase 를 취소하고 싶다면 위 명령어를 입력하면 된다.

04. Github 에서 Branch 활용하기 (Pull Request)

1) pull request 의 개념과 목적

Pull Request: Github에서 제공하는 기능으로, 기존 Github저장소에 보관된 코드 베이스에서 나의 작업으로 생긴 변경사항들(수정, 추가, 삭제)을 코드베이스에 포함시켜달라고(merge 시켜달라고) 보내는 요청

Pull Request 를 하는 이유

1. 내가 작성한 코드가 바로 merge 될 경우 발생할 수 있는 문제를 미리 방지
2. 현재 코드에 대한 코드 리뷰를 진행
3. 프로젝트에 대한 진행 상황을 관리

2) pull request 하는 법

기본이 되는 브랜치가 아닌 수정 사항이 생긴 브랜치에 push를 하게되면 위와 같이 레포지포리 상단에 'Compare & pull request'가 생긴다.
'Compare & pull request' 클릭한다.

위처럼 나오는데 제목에는 자신이 추가한 내용을 커밋메세지와 비슷하게 정해놓은 양식으로 입력해주면 된다.

• 현재 PR 요약/개요
• 코드 변경 이유 (작성 이유)
• 관련 스크린샷
• 테스트 내용
• 리뷰 관련 요청사항

아래 칸 내용에는 보통 위와 같은 내용으로 작성하기도 한다.

3) pull request 에서 코드 리뷰 작성 후 병합하기

위에 화면 오른쪽 상단에 files changed 버튼을 누르면 어떤 것들이 바뀐지 확인할 수 있다.
그 수정 사항에 대해 코멘트를 작성할 수 있다.

그리고 전체적인 리뷰 코멘트를 남기면서,
만약 바꿀 것이 없다면 approve(승인)을 체크하고,
바꿀 것이 있어 보인다면 request changes(수정 요청)를 체크하고
submit review를 하면 된다.

🎈 만약 brach 보호 기능을 사용하지 않는다면 꼭 위 과정을 하지 않고 머지를 할 수 있다. (개인 프로젝트 같은 작은 프로젝트에서)

그리고 리뷰가 문제 없이 끝났다면 사진 왼쪽 하단에 있는 merge pull request 버튼을 눌러서 merge를 진행하면 된다.

마지막으로 커밋 메세지를 적을 수 있는 창이 표시되고, 입력을 다하면 confirm merge 버튼 누른다.

추가로 pull request 후에 브랜치를 더 사용할 일이 없다면 브랜치를 삭제해준다.

4) pull request 완료 후 로컬에 반영하기 (git fetch —prune)

원격에서 이루어진 pull request 작업을 로컬 코드에 적용하기

git pull origin [main]

이제 로컬 main 브랜치와 github main 브랜치가 동일해졌다.

또한, 로컬 git은 github에서 삭제된 브랜치의 상황에 대해서 알지 못한다.

git fetch --prune

위 명령어를 입력하여, 우리 로컬 git이 github(원격, 온라인)상에서 브랜치가 삭제되었음을 알게된다.
그리고 로컬에서 삭제된 브랜치를 삭제해준다.

05. Github 자체 기능 활용하기

1) issue, label, milestone 의 개념

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

label 은 특정한 issue가 어떤 카테고리에 해당하는지를 알려주는 역할을 합다.
label은 보통 팀마다 미리 label을 미리 만들어놓고 프로젝트를 진행한다.
라벨을 활용하면 이슈를 클릭해보지 않고도, 해당 이슈가 뭐와 관련된 것인지를 알 수 있다.

milestone: issue 의 집합이며 milestone에 각 이슈들이 진행상황을 쉽게 알 수 있다.

2) issue 와 pull request 함께 사용하기

pull reques 할 때 내용에 close [이슈번호]를 입력하고 merge하게 되면 동시에 이슈가 자동으로 닫힌다.

3) wiki 를 활용해서 프로젝트 자체 문서 관리하기

wiki 는 github repo 내부에 프로젝트와 관련된 문서를 작성할 수 있는 기능

wiki는 레포지토리 상단 메뉴 중에 있으며 마크다운으로 문서를 작성할 수 있으며 보통은 아래와 같은 내용을 작성한다.

• 서비스 소개 (readme.md 에 다 적지 못한 부분 등)
• 서비스 기능
• 매뉴얼 (개발자 혹은 사용자를 위한)
• 해당 프로젝트에 기여하는 방법 (how to contribute)

4) github actions 에 대해서

github actions: repo에서 특정한 이벤트가 발생했을 때 자동으로 특정한 작업이 실행되도록 하는 기능

예를 들어, main으로 특정한 브랜치가 merge되었을 때 자동으로 main 브랜치에 있는 코드가 서버에 배포되도록 하는 식으로 사용할 수 있다. 또한, CI/CD (자동 빌드 및 자동 배포), 테스트 등 다양한 기능을 구현할 수 있다.