[4일차] Git Marge

Git을 사용한 협업의 핵심, '병합(Merge)'

브랜치는 왜 만들까?

Git에서 브랜치(branch)를 새로 만든다는 것은 곧 **"협업"**의 시작을 의미했다. 여러 개발자가 동시에 각자의 기능을 개발하기 위해 독립적인 작업 공간(브랜치)을 만드는 것이다.

병합의 흐름: Pull Request

개발이 완료된 브랜치(추가 가지)는 기본이 되는 base 브랜치(주로 main 또는 develop)에 합쳐져야 했다. 이 과정을 '병합'이라고 부른다. 우리는 주로 GitHub을 통해 이 병합 과정을 진행했다. GitHub에서는 main 브랜치를 보호(Protect)하여 아무나 직접 코드를 수정할 수 없도록 설정할 수 있었다. 그래서 "제가 만든 feature 브랜치를 main 브랜치에 병합해주세요!"라고 요청하는 Pull Request(PR) 기능을 사용했다. PR을 생성하면, 병합 시 발생할 수 있는 코드 충돌(Conflict)을 GitHub이 자동으로 확인해주어 매우 편리했다. 리뷰어는 PR 메시지를 통해 변경 사항을 쉽게 파악할 수 있었다.

병합 후 정리하기

PR이 승인되고 merge가 완료되면, main 브랜치에는 merge commit이라는 기록이 남게 된다. 병합이 완료된 기능 브랜치는 더 이상 필요 없으므로 삭제해주는 것이 깔끔했다.

로컬 저장소 동기화하기
GitHub(원격 저장소)에서 브랜치가 병합되고 삭제되었다면, 내 컴퓨터(로컬 저장소)에도 이 변경 사항을 반영해주어야 했다.

 

순서
git fetch -p
원격 저장소의 최신 정보를 가져온다. 특히 -p(--prune) 옵션은 원격에서 삭제된 브랜치 정보를 로컬에도 반영하여 정리해준다.

git branch -r,  git branch 

목록을 확인해준다, -r은 원격을 뜻함(깃허브)
git checkout main
main 브랜치로 이동한다.
git pull origin main
원격 main 브랜치의 최신 내용을 내 로컬 main 브랜치로 가져와 동기화한다.
git branch -d feature/login
로컬에 남아있던, 이제는 필요 없어진 feature/login 브랜치를 삭제한다.
이러한 과정을 통해 우리는 Git과 GitHub을 이용하여 체계적이고 안전하게 협업을 진행할 수 있었다.

 

 

깃 브랜치 생성

깃 브랜치 삭제

깃 브랜치 커밋

커밋후 푸시

브랜치 변경

브랜치 변경2

브랜치 깃허브 업로드

풀 리퀘스트

 

로그인 브런치와 합쳐진 메인 브런치

 

브랜치 충돌

충돌내용

Mark as resolved

커밋 히스토리