ETC.

Github

협업을 위한 Github 사용법

이-프 2023. 9. 18. 11:46

Github전략

  1. Git Branch 전략 - Git Flow

    이번 프로젝트에서 처음으로 Git 브랜치 전략을 사용해서 협업을 진행했다. Git 브랜치 전략이란, Git 브랜치를 효과적으로 관리하기 위한 워크플로우이다. 그 중, 우리 팀은 Git Flow 방식을 사용했다.

    ❓
    Git Flow 방식에서 사용되는 브랜치
    • Main 브랜치 : 출시 가능한 프로덕션 코드를 모아두는 브랜치
    • Develop 브랜치 : 다음 버전 개발을 위한 코드 (개발 완료 → Main 브랜치로 머지)
    • Feature 브랜치 : 하나의 기능을 개발하기 위한 브랜치
      • 형태 : feature/branch-name

        └ “git flow integration plus” 플러그인을 사용하면 바로 생성가능

    • Release 브랜치 : 소프트웨어 배포를 준비하기 위한 브랜치
      • 소소한 데이터를 수정하거나, 배포전 사소한 버그를 수정하기 위해 사용됨
      • 배포준비가 완료되면, Main과 Develop 브랜치에 둘다 머지함
      • 형태 : realese/v1.1
    • Hotfix 브랜치 : 이미 배포된 버전에 문제가 발생시 사용
      • 문제가 해결되면, Main과 Develop 브랜치에 둘다 머지함
      • 형태 : hotfix/v1.0.1
    ❓
    Git Flow 협업 전략
    1. IntelliJ의 플러그인 “Git Flow Integration Plus”를 다운받는다.

      이 플러그인을 사용하면, 직접 스위칭, merge 등을 해야했을 때와 달리, 플러그인이 이벤트를 자동으로 진행시켜준다.

    1. 현재 브랜치가 develop브랜치임을 확인한다.
    1. Start Feature 을 선택 후, 구현할 기능에 맞는 브랜치 이름을 설정한다.
    1. 자세한 Commit과 함께 기능을 개발 후, Repository에 push를 한다.

      git push origin feature/<생성한 feature브랜치 이름>

    1. merge를 위한 Pull Request를 생성한다.
    1. 코드리뷰 후, 팀원 2명 이상의 approve 받아야 merge를 진행한다.
    1. Finish Feature 를 통해 feature 브랜치 삭제

  1. Git Clone

    팀원들과 협업을 할때, 회의 하에 dependencies와 같은 기본 설정을 맞춘 init 파일을 clone 받아와 개발을 진행해야 한다. 이는 이후 개발 환경 세팅 불일치로 인한 충돌을 막기 위한 작업이다.

    이 과정에서 내 컴퓨터는 default 브랜치로 main이 아닌 master 브랜치가 되있음을 확인할 수 있었다. 팀원들과 GitFlow 전략을 사용하면서 main브랜치를 사용해야 했기에 default 브랜치 변경 명령어를 사용해야했다.

    git config --global init.defaultbranch main : default branch를 main으로 바꾸는 방법
    ❓
    Git Clone 방법
    1. IdeaProject 폴더에 새로운 폴더 생성하기
    1. 이후, IntelliJ에서 open 후, 아래 코드 진행
    1. git config --global init.defaultbranch main : default branch를 main으로 바꾸는 방법
2. git init
3. git remote add origin "~~~"
4. git fetch
5. git checkout develop
6. git checkout main
7. git pull origin main
8. git checkout develop
=> GitFlow에 체크박스 체크 + main + develop 순으로 ok 후, start feature로 브랜치 생성하기

  1. Pull-Request 방법

    팀 프로젝트를 하다보면, main 브랜치에 무작위로 코드를 push하다보면, 에러가 있는 코드 또는 충돌이 나는 코드들이 합쳐질 수 있다. 이를 방지하기 위해, 팀원들에게 코드리뷰를 받고, CI를 사용하여 test시 에러가 나지 않음을 재차 확인하여 merge를 진행한다.

    이전 프로젝트에서는 PR을 하지 않고, 매번 zoom과 같은 비대면 회의를 통해 코드리뷰를 진행하고 merge를 진행했던 경험이 있다. 이번 프로젝트에서는 PR를 사용하면서 이전 commit으로부터 달라진 점들도 한눈에 파악할 수 있고, 수시록 코드를 리뷰할 수 있음을 깨닫게 되었다.

    ❓
    Pull-Request 방법
    • Fork
      • 타겟 프로젝트의 저장소를 자신의 저장소로 fork
    • clone, remote 설정
      • fork한 브랜치의 URL을 clone

        git clone “~~fork한 브랜치의 URL ~~”

      • 로컬 저장소에 원격 저장소를 추가

        git remote add origin(별명) “원본계정 URL~~”

    • branch 생성
      • git checkout -b 브랜치명
    • 수정 작업 후 add commit push
    • PR생성
      • push 완료 후 Compare & pull request를 활성화하여 PR생성
    • 코드리뷰, Merge Pull Request
      • PR을 받은 원본 저장소 관리자는 코드 변경내역을 확인 후, Merge 여부를 결정
      • 코드 리뷰 및 기능 제안 등 PR에 code에 Comment가 달리면 Conversation이 시작된다.
      • PR 작성자는 코드 리뷰 확인 및 기능 제안에 맞는 기능 구현 등 피드백을 반영한 후 댓글이나 이모지를 통해 반영했음을 알린다.
      • 코드 리뷰 및 기능 제안을 한 팀원은 이를 확인 하고 해당 Conversation을 Resolve한다.
      • 모든 Conversation이 Resolve된 후 PR Merge를 수행한다.
    • Merge 후, branch 삭제 및 동기화
      • 코드 동기화

        git pull origin(별명)

      • 브랜치 삭제

        git branch -d 브랜치명


Uploaded by N2T

'Github'의 다른글

  • 현재글협업을 위한 Github 사용법

티스토리툴바