군만두의 IT 개발 일지

패스트캠퍼스 백엔드 개발 부트캠프 8기 그룹 스터디 - Git 브랜치 전략과 협업 플로우 실습 본문

개발일지/패스트캠퍼스

패스트캠퍼스 백엔드 개발 부트캠프 8기 그룹 스터디 - Git 브랜치 전략과 협업 플로우 실습

mandus 2024. 3. 14. 22:46

목차

    ⭐ 요약


    • 멘토링에서 추천받은 도서관 관리 시스템 개발을 시작하면서, 팀 협업을 위한 Git 사용 방식을 정리한다.
    • GitHub 조직 레포지토리 생성, 커밋 컨벤션 적용, PR 템플릿 세팅 등 협업 환경을 구성한다.
    • 브랜치 전략과 merge 방법, 충돌 해결 방법을 직접 실습하면서 팀원들이 Git에 적응하는 시간을 가진다.

    ⭐ 개발 시작 전 협업 규칙 정리


    본격적인 개발에 들어가기 전, 팀원들과 함께 협업 방식을 먼저 정했다. 코드보다 협업 규칙이 먼저라는 생각으로 아래 사항들을 합의했다.

    • 개발 일정: 우선 월요일 저녁까지 완료를 목표로 하고, 진행이 어려우면 수-목까지 연장한다.
    • Git 전략: 현재는 별도의 브랜치 전략(git flow 등)을 사용하지 않고, 개인 브랜치에서 작업 후 PR을 올리는 방식으로 진행한다.
    • 커밋 컨벤션: 커밋 메시지 규칙 가이드를 따른다.
    • PR 템플릿: 팀장 님이 GitHub PR 템플릿 세팅을 진행했다. ([Git] GitHub pull request template 만들기 참고)
    • 레포지토리: GitHub 조직 계정에 도서관 레포지토리를 생성한다.

    ⭐ 역할 분담


     

    담당 도메인 담당자
    Book (도서 관리) 팀원A
    User (회원 관리)
    Loan (대출 관리) 팀장
    Reservation (예약 관리) 팀원B

    ⭐ Git 사용법 정리


    1. 기본 push 흐름

     

    개인 브랜치(user.branch)에서 작업하면서 아래 순서로 push를 진행했다.

    git pull origin main   # 원격 main 브랜치의 최신 내용을 먼저 받아온다.
    git add .
    git commit -m "message"
    git push origin user.branch

     

    2. 권장 push 흐름: main을 먼저 최신화한 뒤 merge

     

    위 방식보다 충돌을 사전에 줄이고 더 안전하게 push하는 방법은 아래와 같다. main 브랜치로 먼저 이동해서 최신 내용을 받아온 뒤, 내 브랜치로 돌아와서 main을 merge하고 push하는 것이다.

    git checkout main          # main 브랜치로 이동한다.
    git pull                   # 원격 main의 최신 내용을 받아온다.
    git checkout user.branch   # 내 브랜치로 돌아온다.
    git add .
    git commit -m "message"
    git merge main             # main 브랜치의 내용을 내 브랜치에 병합한다.
    git push origin user.branch

     

    3. PR merge 방법: 팀원A 님이 공유한 내용

     

    팀원A 님이 PR을 merge하는 올바른 방법을 채팅으로 공유해주셨다. 항상 main을 먼저 최신 상태로 만든 뒤 내 브랜치와 merge하는 것이다.

    # 1. main 브랜치에서 원격 저장소의 최신 내용을 로컬에 반영한다.
    git checkout main
    git pull origin main
    
    # 2. 내 브랜치로 이동 후 main을 merge한다.
    git checkout user.branch
    git merge main
    
    # 3. 충돌이 발생하면 '<<<<' 표시가 있는 부분을 직접 수정한다.
    #    수정 완료 후 커밋하고 PR을 올린다.
    git add .
    git commit -m "message"
    git push origin user.branch

     

    4. 최후의 수단: 강제 리셋

     

    충돌이 너무 심하거나 브랜치 상태가 꼬였을 때는 특정 커밋 시점으로 강제 되돌리는 방법을 사용한다. 단, --hard 옵션은 작업 내용이 모두 사라지므로 신중하게 사용해야 한다.

    # 특정 커밋 시점으로 강제 리셋한다. (이후 작업 내용은 모두 삭제된다.)
    git reset --hard [커밋 해시]
    
    # 이후 원격 main의 최신 내용을 다시 받아온다.
    git pull origin main

     

    ⭐ 트러블슈팅


    문제: 팀원B 님의 git push 오류

     

    23시경 팀원B 님이 git push 하는 과정에서 오류가 발생했다. 팀원A 님이 원인을 파악하고 해결해주셨다.

    항목 내용
    원인 .idea 폴더가 .gitignore에 등록되지 않아 발생한 충돌 문제
    해결 .gitignore 파일에 .idea를 추가하여 push

     

    .gitignore에 아래 항목들을 추가하면 IntelliJ IDEA의 설정 파일이 원격 저장소에 올라가지 않는다.

    ### IntelliJ IDEA ###
    .idea
    *.iml
    out/

     

    ⭐ 어려웠던 점


    • 처음 팀 협업으로 Git을 사용하다 보니 브랜치 간 충돌이 발생하는 경우가 잦았다. <<<< 충돌 표시를 직접 수정해본 경험이 없는 팀원도 있어서, 이 부분을 팀 전체가 함께 익히는 시간이 필요했다.
    • IntelliJ의 .idea 폴더가 .gitignore에 등록되지 않으면 팀원마다 다른 IDE 설정이 충돌을 일으킬 수 있다. 프로젝트 시작 시 .gitignore를 먼저 세팅하는 것이 중요하다는 점을 배웠다.
    • PR 템플릿, 커밋 컨벤션 등을 팀 전원이 동일하게 적용하려면 초반에 규칙을 맞춰야 한다.

    ⭐ 후기


    • 협업에서는 브랜치 관리와 merge 전략이 코드만큼이나 중요하다는 것을 직접 느꼈다.
    • 오류가 생겼을 때 팀원이 바로 도움을 주는 환경이 든든했다. 협업의 장점은 문제를 혼자 끌어안지 않아도 된다는 점인 것 같다.
    • 앞으로는 git merge 전에 항상 git pull로 main을 최신 상태로 만드는 습관을 지킬 예정이다.

     

    이 글은 패스트캠퍼스백엔드 개발 캠프에서 공부한 내용을 작성한 것입니다.
    Comments