[Git 협업] Forking Workflow 방식

샤이니·2022년 4월 6일
0

잡학사전

목록 보기
1/18
post-thumbnail
post-custom-banner

Git 협업

Github으로 협업하는 이유와 방법

왜 git으로 협업해야 하는가?


1. 소스코드, 프로젝트의 공유가 편리하다. Git은 분산형 버전 관리 시스템으로 코드 뿐만 아니라 코드의 변경 내역까지 모두 가져올 수 있다.

  1. 포트폴리오 관리에 용이하다.

Forking Workflow

  • 모든 프로젝트 참여자가 개인 로컬 저장소와 공개된 자신의 원격 저장소(중앙 원격 저장소를 fork한 것), 이 두개의 저장소를 가지고 협업을 진행하는 방식이다.

  • 모든 코드 기여자가 중앙 저장소에 푸시하는 것이 아니라, 각자 자신의 원격 저장소에 푸시하고 이 내용을 중앙 원격 저장소에 Pull Request 한다. 그리고 프로젝트 관리자(Owner)가 다른 개발자들의 기여분(PR)을 중앙 원격 저장소에 병합할지 안할지 결정하는 것이 특징이다.

  • 오픈소스 프로젝트에 많이 사용하는 방식

  • 다른 방식들 참고
    https://devlog-h.tistory.com/6

중앙 원격 저장소, 자신의 원격 저장소, 로컬 저장소 개념

  • 중앙 원격 저장소 : 여러 명이 같은 프로젝트를 관리하는 데 사용되는 그룹 계정(Organization)의 중립된 원격 저장소
  • 자신의 원격 저장소 : remote repository, 내 깃허브의 repository
  • 로컬 저장소 : local repository, 내 PC에 저장되는 개인 전용 저장소

forking workflow 협업의 큰 틀

  1. 프로젝트 repository를 fork해 개인 github에 복사한다
  2. 각자의 로컬 환경에서 개발한 내용을 upstream에 pr한다.
  3. 리뷰를 통해 최종 수정된 pr은 upstream에 merge한다.
  4. 변경된 upstream의 내용을 pull 명령어로 로컬에 반영한다.
  5. 2번~4번을 반복한다

프로젝트 가져오기

  1. 중앙 원격 저장소인 프로젝트 repository 개설 후 중앙 원격 저장소를 fork해 자신만의 개인 원격 저장소를 만든다.
  • 중앙 원격 저장소를 나의 깃허브 계정 저장소에 복제한다는 개념.
  • 자신의 깃허브 계정에 중앙 원격 저장소와 똑같은 내용의 저장소가 복제된다.
  • 개인 공개 저장소로 저장되므로 중앙 원격 저장소와 독립적으로 운영된다.
  1. 프로젝트 참여자는 git clone 명령으로 로컬 저장소를 만든다.(최초 1회)
    git clone [fork해 온 개인 원격 저장소 https url]
  1. 중앙 원격 저장소와의 연결을 위해 프로젝트에 upstream을 설정한다.
    git remote add upstream [중앙 원격 저장소 레포의 https url]
  • 깃허브 저장소에 push 하거나 pull 할때 매번 url를 작성하기 번거롭기 때문에 각 url에 이름을 붙여줄 수 있다.
  • 아무렇게나 이름을 붙여도 상관업지만, 일반적으로 자신의 원격 저장소는 origin, 프로젝트 중앙 원격 저장소는 upstream으로 이름 붙인다.
    • Origin : Fork를 통해 복사해 내 github에 생성된 repository, 즉 나의 작업 내용을 push하는 공간
    • Upstream : 가장 근본이 되는 repository. 오류가 없는 최종적인 코드가 저장되는 공간
  1. 브랜치를 생성한다.
  • 새로운 기능 개발을 위해, main 브랜치와 격리된 새로운 branch를 만들어야한다.
  • 구현할 기능 이름으로 브랜치 이름을 짓는다. (ex. map branch, weapon branch . . .)
  • 주의! 반드시 main 브랜치에서 브랜치를 생성해야 한다!
  • 브랜치란?
    • 여러 명이서 동시 작업을 할 때, 다른 사람의 작업에 영향을 주거나 받지 않도록 하는 자신의 독립적인 작업 단위
    • 브랜치로 그 작업의 기록을 중간중간에 남기게 되므로 문제가 발생했을 경우, 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워진다.
git branch [branch name] // 새로운 브랜치 생성
git checkout [branch name] // 해당 프랜치로 작업 위치 이동

git checkout -b [branch name] // 위 두 명령어를 합한 것

git branch -d [branch name] //브랜치 삭제
git branch // 전체 브랜치 조회
  • 여기서 origin의 main branch는 오류없이 정상작동하는 마지막으로 pull한 code
  • origin의 새로 생성한 branch는 문제 발생 시 삭제해도 괜찮은 branch로 현재 작업중인 코드가 있는 branch이다.
  1. 로컬 저장소에서 커밋한 이력을 자신의 원격 저장소로 push 한다.
  • 기능 구현을 마친 후 커밋한 내용을 푸시 할 때는 복제(clone)했던 자신의 원격 저장소로 푸시한다.
  • 푸시하고 나면 나의 원격 저장소에도 똑같은 브랜치가 생긴다.
// 자신이 변경, 추가한 모든 파일을 스테이징 영역(커밋 준비 상태)에 추가
git add . 

// add 한 파일들을 커밋한다.
git commit -m "커밋 메세지" 

// [branch name]에 해당하는 브랜치를 자신의 원격 저장소에 push
git push origin [branch name]
  • commit rule
    • 유의미한 Commit message 작성하기
    • Commit message를 통해 작업 내용을 쉽게 유추할 수 있도록 작성하는 것이 중요하다.
    • 팀별로 규칙을 생성하는 방법도 추천!
    • 보통은 Angular JS Git Commit Message Conventions Document 를 따른다

      feat : 새로운 기능
      fix : 버그 수정
      build : 빌드 관련 파일 수정
      chore : 그 외 자잘한 수정
      ci : CI 관련 설정 수정
      docs : 문서 수정
      style : 코드 스타일 혹은 포맷 등
      refactor : 코드 리팩토링
      test : 테스트 코드 수정

  1. 작업한 내용 올리기
  • 내가 만든 기능을 중앙 원격 저장소에 반영하기 위해선, 프로젝트 관리자에게 반영 요청(pull request)해야 한다.

  • 나의 원격저장소 깃허브 페이지에서 구현한 기능의 브랜치를 선택해 pull request 버튼을 눌러 요청한다.

    • Github에서 origin 혹은 upstream repository 접속
    • 초록색의 compare & pull request 버튼을 눌러 pr 작성
    • Git add, commit, push가 정상적으로 완료된 상태라면 버튼이 활성화 된다.
  • PR 작성법

    • 제목에 작업 내용 간단히 요약 후 내용에 작성한 부분에 대한 자세한 설명한다. 또한 Pr에 해당하는 label이나 issue 추가한다.
    • Pr에 수정사항이 생긴 경우, 로컬에서 작업하던 브랜치에서 이어서 수정한다.
    • 수정한 작업 내용을 그대로 git add, commit, push 하면 pr에 자동으로 해당 커밋이 올라간다.
  • PR 리뷰하기

    • File changed를 통해 모든 파일의 변경사항 확인 가능하다.
    • 코드를 읽으며 수정이 필요한 라인에 마우스 커서를 가져다 대면 + 버튼이 생성되어 클릭 시 코멘트를 남길 수 있다.
    • 로컬에서 pr 내용 실행해볼 수도 있다. pr을 실행해보는 경우 브랜치를 새로 생성해 작업하는 것이 좋다.
      git pull [pr올린 팀원 repogitory https url] [팀원의 작업 branch 이름]
  1. 프로젝트 관리자는 변경 내용을 확인한 후 중앙 원격 코드에 병합(merge)한다.
  • 모든 팀원이 변경한 코드 내용을 확인하고 프로젝트 관리자는 병합(merge)를 진행한다.
  • Pr을 받은 중앙 원격 저장소 관리자는 변경 내용을 확인한 후 중앙 원격 코드 베이스에 병합(merge)여부를 결정한다.
  • 충돌이 일어날 수 있으니 꼼꼼히 확인 후 merge해 main에 코드를 반영해야한다.
  • 병합에 성공하면 중앙 원격 저장소의 main branch에 해당 내용이 갱신된다.
    • merge한 branch는 delete branch를 해주는 것이 관리에 좋다.
  1. 중앙 원격 저장소와 자신의 로컬 저장소를 동기화해 최신화시킨다
  • 중앙 코드 베이스가 변경되었으므로, 자신의 로컬 저장소를 동기화 해서 최신상태로 만들어야한다.
  • 최신상태로 만들기 이전에 로컬 저장소 작업 위치를 main 브랜치로 이동해야한다.
  • 주의! 반드시 master 브랜치로 이동 한 후 새로운 내용(중앙 원격 저장소 변경 내용)을 받아와야 한다.
git checkout main

git pull [pr올린 팀원 repository https url][팀원의 작업 branch 이름]
  1. 중앙 원격 저장소의 코드 베이스에 새로운 커밋이 있다면 로컬 저장소에 갱신한다.
  • 중앙 코드 베이스가 변경되었으므로, 모든 프로젝트 팀원은 자신의 로컬 저장소를 동기화 해서 최신상태로 만들어야한다.
  • 아래의 명령어를 이용해 최신 상태로 동기화 한다.
 git pull upstream main
  • 반드시 main 브랜치에서 갱신해야한다!

최종정리

git clone [fork해 온 내 깃허브 레포의 https url]

git checkout -b [branch name] // 새로운 브랜치 생성 후 해당 브랜치로작업 위치 이동
git branch -d [branch name] //브랜치 삭제

git add . 
git commit -m "커밋 메세지" 

git push origin [branch name] 

git checkout main
git pull upstream main

협업을 위한 꿀팁!

  1. Issue를 등록해 작업 목록을 정리하자.
    Pr 라벨을 추가해 작업 유형을 나타내자.
  2. 커밋 단위는 세세하게 나누어 혹시 모를 문제 상황에 대비하자.
  3. 구글 드라이브, 슬랙, 디스코드, 트렐로, 노션 등 협업 툴을 사용하자!
    우리 팀만의 협업 룰을 정하자

reference

GitHub] GitHub로 협업하는 방법[2] - Forking Workflow

Git으로 협업하기! - forking workflow에서 git flow로 변경한 이유

알아서 잘 딱 깔끔하고 센스있게 정리하는 GitHub 핵심 개념

post-custom-banner

0개의 댓글