[Git] Git branch전략, Pull Request, merge | Git 브랜치 전략 기반의 협업 워크 플로우

여러분 잘 지내셨나요?
이전 글에서 branch, checkout, -d등 깃 브랜치와 명령어에 대한 내용을 학습하였는데요! 오늘은 두 가지의 깃 브랜치 전략과 pull request, merge에 대한 내용을 자세히 다루려고 합니다>.<
파이팅!! ٩( *˙0˙*)۶. 

<이전 게시글> https://jungheeho.tistory.com/26

[웹 풀사이클 데브코스 TIL] 깃 브랜치, 명령어 정리(branch, checkout, -d)👩🏻‍💻_DAY5

 

✔️깃 브랜치 이름 규칙

main branch는? 만약 v1.2일 때

- 기능 개발 : feature/login, feature/select-product

- 출시 준비 : release-1.3, release-1.4 (업데이트할 때)

- 긴급 수정 : hotfix-1.2.1 (버그 긴급 수정하거나 할 때

 

♟️깃 브랜치 전략(= =git flow )

- 브랜치 전략은 소프트웨어 개발 과정에서 코드의 버전 관리를 체계화하기 위해 사용됩니다. 이 전략은 다양한 기능 개발, 버그 수정, 실험 등을 병렬적으로 진행할 수 있게 해 줍니다.

주요 브랜치 : master, develop, feature, release, hotfix 등

 

💡Merge

Fast forward Merge

• 정의: fast-forward 병합은 병합하려는 브랜치가 현재 브랜치의 직접적인 앞선 이력을 가지고 있을 때 사용되는 방법. 이 경우, 병합하는 브랜치의 커밋들은 현재 브랜치의 이력에 아직 존재하지 않기 때문에, 단순히 현재 브랜치의 포인터를 병합하는 브랜치의 최신 커밋으로 옮기기만 하면 됨.
• 특징: 이 방식은 별도의 병합 커밋을 생성하지 않기 때문에, 프로젝트의 커밋 히스토리가 깔끔하게 유지됨.

3-way Merge

• 정의: 3-way merge는 두 브랜치의 최신 커밋들과 이들의 공통 조상 커밋을 기반으로 새로운 병합 커밋을 생성하는 방식. 이는 두 브랜치가 서로 다른 변경 사항을 가지고 있을 때 적용.
• 특징: 이 방식은 병합 시 충돌이 발생할 수 있으며, 충돌을 수동으로 해결한 후 병합 커밋을 생성해야 함. 병합 커밋은 두 브랜치의 변경사항을 포함하며, 프로젝트의 이력에 병합 사실을 명확하게 남김.

두 브랜치 전략의 차이점

• 병합 커밋 생성 여부: fast-forward는 별도의 병합 커밋을 생성하지 않지만, 3-way merge는 새로운 병합 커밋을 생성.
• 적용 상황: fast-forward는 병합하려는 브랜치가 현재 브랜치의 직접적인 연장선상에 있을 때 사용되고, 3-way merge는 두 브랜치가 독립적으로 진행된 경우 사용.
• 히스토리 유지: fast-forward 방식은 이력을 선형적으로 유지하는 반면, 3-way merge는 브랜치 병합의 이력을 명확하게 남김.

 

📢 PR(Pull Request)

- Pull Request는 사용자가 원격 저장소에 Push 하여 새로운 변경사항이 추가되었을 경우, 푸시된 상황을 다른 사용자에게 알려 병합을 요청하는 것입니다.

 

1. 원격 저장소에 푸시하면 Github에서 해당 리포지토리 상단에 Compare & pull request라는 버튼이 뜸

2. 해당 버튼을 클릭하면 Push 한 내용은 간단하게 요약해서 알려줄 수 있는 입력칸이 등장하고, 메시지를 작성 후 우측 하단의 Create pull request 버튼을 클릭하여 PR 전송

3. PR을 보내놓으면 여러 동료들에게 코드리뷰를 받을 수 있고, 내가 올린 코드에 동료가 병합하여 진행할 수 있음

 

---

🤝🏻 전체적인 협업 워크 플로우

1. 로컬 저장소 작업:
   • git pull으로 최신 코드를 가져옴 + 새 기능, 버그 수정을 위해 git checkout -b [브랜치명]으로 새 브랜치 생성
2. 변경 사항 커밋:
   • 작업 내용을 git add로 스테이징, git commit -m "[커밋 메시지]"로 변경 사항을 커밋
3. 원격 저장소에 푸시:
   • git push origin [브랜치명]으로 로컬 브랜치의 변경 사항을 원격 저장소에 푸시
4. Pull Request 생성:
   • GitHub에서 Pull Request를 생성하여 병합 요청(제목, 설명, 리뷰어 등 필요한 정보 입력)
5. 코드 리뷰 및 논의:
   • 다른 개발자들이 코드를 리뷰하고 논의(+필요한 경우 추가적인 수정)
6. Pull Request 병합:
   • 모든 리뷰가 완료되고 체크가 통과되면, "Merge" 버튼을 클릭하여 대상 브랜치에 병합
7. 로컬 저장소 업데이트:
   • 병합 후에는 git checkout [대상 브랜치]와 git pull로 로컬 저장소를 업데이트

 

 

다음 시간에 만나보아요 ◕‿◕✿

 

---

🍀 느낀점 및 정리

브랜치 생성부터 PR, merge까지 깃을 통한 전체적인 협업 과정을 학습할 수 있어서 유익한 시간이였습니다. GitHub Desktop을 통해 GUI로만 push, merge 하다가, CLI를 사용하여 push, pull하며 전체적인 로직과 내용을 완벽하게 익힐 수 있어서  좋았습니다.🚀👩🏻‍💻