모르는 걸 즐기자!
이번에 처음으로 제대로 된 협업을 경험하면서 이슈, PR(Pull Request), Squash and Merge 같은 용어들을 실제로 사용해보았다. 단어들은 익숙했지만, 어떻게 효율적으로 활용하고 왜 사용하는지에 대해서는 잘 알지 못했다. 다행히도 경험이 풍부한 팀원 덕분에 그 의미와 사용 방법을 쉽게 이해할 수 있었고, 협업의 효율성을 높이는 방법도 배울 수 있었다.

🤔 이슈(issue)?

깃허브에 레포지토리(Repository) 를 생성하게 되면 Issues 라는 것을 많이 봤을 것이다. 이슈(Issue)? 뭔가 무언가 안좋을일이 있을 때 컨디션 이슈, 날씨 이슈 라는 표현을 종종 사용했는데 안좋은 표현같지만 그렇지 않다.

• 이슈(issue)란 프로젝트에서 작업해야할 단위를 의미한다.
• 프로젝트에서 작업해야하는 작업들(개발해야하는 기능, 버그 발생, 리팩터링) 등을 생성하여 관리하는 것이다.
• 협업을 할 때, 누가 어떤 작업을 해야하는지, 얼마나 진행했는지를 효과적으로 파악할 수있으며, 나중에 PR을 할때 이슈 번호를 적어 어떤 작업을 했는지 쉽게 파악이 가능하다.

이슈(Issue)의 Flow

1. A라는 사람이 회원가입 기능을 개발해야 하는 상황 발생

2. 회원가입 기능에 대한 Issue 생성(기능 설명 작성 (무엇을 할 것인지, 완료 기준 등))

3. develop 브랜치에서 feature/회원가입(feature/이슈번호)같은 feature 브랜치로 분기

4. 생성한 feature 브랜치에서 회원가입 기능 개발 진행

5. 개발 완료 후 PR(Pull Request) 생성

6. PR 제목이나 본문에 이슈 번호 명시 (ex: Closes #이슈번호)

🤔 협업을 할 때는 이슈(issue) 템플릿을 미리 만들어 놓고 제목과 본문 내용을 어떻게 적을 것인지, 브랜치를 이슈번호를 포함시킬건지 정해 놓는 것이 좋을 것 같다는 생각을 하였다.

PR(Pull Request)

자기가 맡은 기능을 개발한 후, 팀의 dev 브랜치에 merge를 하고 싶으면 PR(Pull Request)을 생성하는 것이 좋다. 위에 이미지는 그냥 "나의 로컬 dev의 변경 사항을 팀의 dev 브랜치에 병합(merge)할거다." 라는 의미지만(그냥 이걸 캡쳐해옴) 원래라면 feat/8(이슈번호,또는 작업 내용) 브랜치를 팀의 dev 브랜치에 병합(merge)하는 방식을 많이 사용한다.

👏 PR의 제목, 본문 내용도 팀과 함께 서로 맞추거나 템플릿을 사용하여 통일시 하는 것이 좋다.

🤔 PR(Pull Request)을 왜 사용하는데?

1. 코드 리뷰를 받을 수 있어서
   → 다른 개발자들이 코드를 확인하고, 문제나 개선점을 찾아준다.
   → 실수를 줄이고, 더 좋은 코드를 만들 수 있다.

2. 협업 흐름을 안전하게 유지할 수 있어서
   → 바로 메인(main/master) 브랜치에 반영하지 않고, 검토 후 병합하므로
   코드가 망가지는 걸 방지할 수 있다.

3. 변경 이력을 깔끔하게 남기기 위해
   → 어떤 기능/버그 수정이 어떻게 이루어졌는지 문서처럼 기록된다.

4. CI/CD 파이프라인과 연계되기 때문에
   → PR이 올라오면 자동 테스트, 빌드 등을 돌려서 코드 품질을 자동 검증이 가능하다.

5. 팀 커뮤니케이션 수단으로서도 유용
   → “이렇게 구현했는데, 더 좋은 방법 없을까요?” 식으로
   피드백 주고받는 장이 된다.

Merge

병합 방식이 많은걸 알고 있었지만 Squash and Merge는 처음 사용해보았다. 그래서 병합 방식도 정리하는 것이 좋을 것 같아 정리할려고 한다.

1) Merge

• 일반적으로 많이 사용하는 병합이고, 커밋(Commit) 이력을 모두 남길 때 사용한다.

git merge my-branch

• 이 방식은 다시 Fast-Forward 방식과 Recursive 방식으로 분리 가능하다.

1-1) Fast-Forward

상황 정리

1. main 브랜치에서 feature 브랜치를 분기함
2. feature 브랜치에서 아무 커밋도 하지 않음
3. 다시 feature 브랜치를 main에 머지함

🔄 그럼 어떻게 병합될까?
이 경우 feature 브랜치는 사실상 main과 동일한 상태이므로
Git은 그냥 브랜치 포인터를 옮기기만 한다.

즉, feature 브랜치가 main에서 한 발짝도 앞으로 나아가지 않았다면,
main 브랜치는 그냥 feature 브랜치 커밋들을 따라잡는 식으로 merge

1-2) Recursive

• feature가 main 브랜치에서 분기되고, main 브랜치에 새로운 커밋이 생겼을 경우,
  feature와 main을 공통 부모로 한 새로운 Merge 커밋을 생성하는 방식

2) Squash Merge

• feature 브랜치의 여러 커밋이 모두 합쳐져 하나의 새로운 커밋을 만들고 난 다음 이전 커밋 내용을 모두 지우는 병합 방식
• 기존 변경사항들이 어떻게 변했는가 보다 merge가 되었다에 좀 더 집중한 전략
• 일반적인 merge보다 남아있는 정보량이 비교적 적기 때문에 merge log를 깔끔하게 남길 수 있지만 언제 어떤 코드를 바꿨는지에 대한 정보를 잃을 수 있다는 단점

3) Rebase Merge

• feature 브랜치의 커밋 내용을 main 브랜치에 재배치하고 추가 커밋 없이 병합하는 방식
• merge를 하면 base가 바뀌지는 않지만, rebase는 단어 그대로 base를 바꿔서 병합

git checkout feature
git rebase main
git checkout main
git merge feature

• rebase?
• 말 그대로 base를 다시 설정한다는 의미
• feature가 분기된 main 브랜치의 최신 커밋
• rebase를 하면 기존 분기점이었던 A 커밋에서 가장 최신 커밋인 C로 base가 설정

🤔 base란 “브랜치가 갈라져 나온 지점” 즉 서로 다른 두 브랜치의 공통 조상(commit) 을 가리킨다.

참고

• [Github 협업, 이것만은 알자] - Issue & PR
• PR(Pull Request)란 ?
• [git] 다양한 Merge 방법 (Merge, Squash and Merge, Rebase and Merge)
  
• 다양한 git merge 방법 (3-way, fast-forward, squash, rebase)
• [Git] Git Merge에 대해 알아보자