TIL 5일차 - git branch

깃 브랜치

 

👉 브랜치란?

버전의 분기를 말하며, 독립적으로 작업을 진행할 수 있도록 해준다.

즉, 버전을 여러 흐름으로 나누어 관리하는 방법이다. 

여러 브랜치를 만들어 각각 작업할 수 있기때문에 여러 기능을 병렬로 개발할 수 있게 해준다.

 

3단계로 버전 관리한다.

1. 브랜치를 나눈다.

2. 각자의 브랜치에서 작업한다.

3. 나눈 브랜치를 합친다

 

👉 git branch 명령어

• 새 브랜치 생성: git branch 브랜치명 => git 안에서만 브랜치를 생성할 때
• 브랜치 목록 확인: git branch (*표시가 있는 브랜치가 현재 작업/위치하고 있는 브랜치)
• 브랜치 삭제: git branch -d [삭제할 브랜치명]
• 다른 브랜치로 이동: git checkout 이동할 브랜치명
• 이전 브랜치로 이동: git checkout -

 

👉 깃 브랜치 이름 규칙

"메인 브랜치" ex)v.1.2.0 - 사용자들이 현재 사용하는 버전을 가지고 있음

복사하는 경우 기능 개발, 출시 준비, 긴급 수정이다.

1. 기능을 개발하기 위한 브랜치 feature/새 기능 (ex. feature/login, feature/select-product ...)
2. 출시 준비하기 위한 브랜치 release-릴리즈 번호 (ex. release-1.3, release-1.4 )
3. 긴급 수정하기 위한 브랜치 hotfix-릴리즈번호.n (ex. hotfix-1.2.1)

 

👉 주의사항

• 새 브랜치 생성 -> 생성한 브랜치에서 작업을 한다 -> 커밋 필수!!   커밋을 하기 전까지는 다른 브랜치와 다르지 않다. 커밋해야만 브랜치에 수정 내용이 반영된다! 커밋해야 병렬 개발이 가능하게된다.
• 커밋하기 전에 꼭 현재 위치한 브랜치를 확인하고 커밋해야한다. 커밋은 rollback이 안되기때문에 커밋한 후 작업 내용이 반영된 브랜치 위치를 바꿀 수 없다.

 

깃허브 브랜치

원격 저장소에 있는 브랜치 목록 확인: git branch -r
깃에서만 브랜치를 생성: git branch [브랜치명]

 

 깃허브에 브랜치 생성하기 (브랜치를 깃허브에 올리기) 

 

깃허브에 브랜치 생성하고 (그 생성한 브랜치에) 깃 브랜치 복제하기 = 깃에 만든 브랜치를 깃허브에 올리기

 

현재 Login Branch Commit이 feature/login 브랜치에만 존재한다.

이 커밋을 origin 밑으로 들어가도록 하고싶다. 

 

git push [깃허브저장소별칭] [깃브랜치명]

 

깃허브 사이트를 확인해보니

feature/login이 푸쉬됐다는 알림창이 떴고

2 branches가 있다고 알려준다.

main을 클릭해보면 feature/login 브랜치가 깃허브에 생성된 것을 알 수 있다.

 

 

 

깃 브랜치 전략(= 깃 플로우)

1. fast forward
2. 3-way

fast forward 전략

A branch에서 B branch를 생성한 시점부터,

• A branch에는 아무런 추가 구현을 하지 않고
• B branch만 추가 구현 한 뒤

B branch와 A branch를 합치면 ==> A branch에 그냥 B branch가 붙으면 끝남

3-way 전략

일반적으로 가장 많이 사용

A branch에서 B branch를 생성한 시점부터,

• A branch도 추가 구현을 하고
• B branch도 추가 구현을 하고

B branch와 A branch를 합치면 ==> A branch와 B branch가 서로 비교하여 바뀐 것을 정리하여 합치는 전략

 

pull request(PR) & merge

 

Pull Request란?

내가 생성한 브랜치에서 수정작업을 한 후 원격 저장소에 내 브랜치를 푸시(push)한다.

그 브랜치가 원본 프로젝트에 병합되도록 요청하는 기능이다.

 

Merge(병합)이란?

브랜치를 생성하는 이유는 협업을 위해서이다.

그래서 주로 브랜치 병함(추가 branch → 다른 base branch로 합치는 것)을 깃허브에서 한다.

 

merge 단계

main branch 보호(proetect)

➡️ 추가 branch를 main branch로 병합 요청 명령(= Pull Request). 이때 PR 메세지 신경써서 작성할 것!

➡️ 깃허브가 충돌 일어나는지 자동으로 확인

➡️ merge (merge commit라는 merge할 때 commit이 발생함)

➡️ branch 삭제

 

Pull Request & merge

Contribute > Open pull request

 

Add a title에 원하는 이름 작성 > Add a description는 신경써서 작성해야함(ex. 주요 구현 내용, 이슈…). 협업 시, 다른 사람들이 참고하기때문 > Create pull resquest

아래를 보면 feature/login에서 main으로 1개의 커밋을 병합하길 원한다는 메세지가 뜨고 작성자가 작업한 내용을 작성한 것이 보인다.

"merge pull request" 버튼을 클릭해서 병합한다.

 

성공적으로 병합(merge)됨.

 

브랜치 사용이 끝나면 merge를 시킨 후에는 필요가 없기때문에 delete branch를 한다.

 

레포지토리를 확인해보면 main branch만 있는 것을 알 수 있다.

 

 

커밋 이력을 보면 병합된 것을 확인 가능

 

 

병합된 깃허브 - 깃 동기화

 

깃허브 홈페이지에서 사용하지 않는 브랜치를 삭제하고 vscode 터미널에서 원격 브랜치 목록을 확인해봤는데 삭제한 브랜치가 존재하는 문제가 생겼다.

 

 

해결방법

깃허브의 브랜치 목록을 동기화하는 명령어 git fetch -p

 

성공적으로 동기화됨

 

 

 

feature/login 브랜치를 삭제하기 위해 checkout을 하여 main으로 이동 > feature/login 브랜치 삭제 > 실패

⚠️ 문제 발생 : 깃허브 홈페이지에서 merge를 했는데 왜 안됐지?

 

깃에 있는 main branch의 log 확인해보니 merge하기 전의 commit까지 존재

(why? 깃허브의 main에만 merge를 하고 깃의 main과 동기화 시키지 X)

 

그래서 origin에서 main을 가져오겠다는 명령을 하여 동기화 시킴

 

git log를 확인해보니 merge 로그를 확인했고 동기화가 제대로 됐음을 확인

 

깃에서 성공적으로 feature/login 브랜치 삭제할 수 있게된다.

 

 

 

충돌 해결하고 병합하기

 

git checkout -t 별칭/가져올 브랜치명 :깃허브에 있는 브랜치 받아오는 명령어 

 

충돌이 발생한 이유?

병합하려는 두 브랜치가 같은 내용을 서로 다르게 수정했기 때문이다.

따라서 충돌이 발생하면 충돌이 발생한 두 브랜치 중 어떤 브랜치의 내용을 병합 결과에 반영할지를 선택하면된다.

 

 

pull request를 했는데 충돌이 일어났다는 알림이 떴다.

resolve conflict 버튼을 클릭

 

그러면 충돌한 브랜치와 코드를 보여준다.

 

병합 결과에 반영할 코드만 남기고 지운다 > Mark as resolved 클릭

 

Commit merge 클릭

 

Merge pull request 클릭까지 하면 성공적으로 병합이된다.