Github 협업

trollering12312·2022년 1월 10일
0

github

목록 보기
4/7
post-thumbnail

팀 프로젝트...

GitGithub은 개인이 프로젝트를 관리하기 위해서도 사용하지만, 팀 프로젝트 용으로 사용하는 경우가 더 많을 거라 생각합니다

Github만 잘쓰면 다른 도구없이 프로젝트를 할 수 있다는 말처럼 정말 강력한 도구인건 분명합니다

이런 깃헙에서 주로 사용하는 협업 방식을 정리해보려고 합니다😑

Fork, PR

많은 팀 프로젝트들은 브랜치보다는 forkPull requests를 활용합니다

프로젝트를 통채로 외부로 복제해서 개발 후 바로 merge 하는게 아니라, fork를 통해 일종의 저장소 사본을 가져와 할당된 작업을 하고 변경내역을 PR(pull request)로 원본 저장소에 merge 하고싶다는 요청을 보냅니다

그러면 원본 저장소를 관리자의 검토를 거쳐 통과하면 merge를 통해 기존 프로젝트에 그 내역이 반영되게 됩니다

저장소 우측 상단에 fork 버튼을 클릭하면 fork되어 내 저장소 목록에 새로운 저장소가 추가됩니다

이후 fork한 저장소에 작업 내용을 push하면 pr 관련 알림이 나타납니다. 만약 알림이 뜨지 않더라도 pr 메뉴에서 원하는 형태로 요청을 할 수 있습니다

Fork 협업 과정 예시

팀장(원본 저장소 관리자)팀원
원본 저장소 생성 및 설정
프로젝트 fork 이후 로컬로 clone
작업할 브랜치 생성 후 맡은 부분 개발
작업 내역을 commit한 뒤, fork한 저장소로 push
깃헙에서 원본 저장소로 pr요청
pr 내용 확인 및 검토검토 내용 따라 수정
메인 브랜치에 merge

Git Flow

fork/pr 방식이외에도 브랜치를 적극적으로 활용해 협업을 할 수도 있습니다

이런 브랜치 협업 방식을 체계화한 다양한 브랜치 모델들(git flow, github flow, gitlab flow...)이 있습니다

이 중에서는 git flow가 가장 많이 사용됩니다. 만약 git-for-windows를 통해 git을 설치한 경우 미리 설치되어있습니다

설치해야한다면 여기를 참고하시면됩니다

a-successful-git-branching-model

git-flow는 브랜치를 더 효율적으로 사용하기위해 Vincent Driessen가 구상한 a-successful-git-branching-model을 쉽게 사용하기위해서 몇 개의 명령으로 구성한 git의 확장판이라고 볼 수 있습니다

a-successful-git-branching-model 원문

다만 이 모델은 프로젝트의 규모가 커지면 많이 복잡해질 수 있기때문에, 무조건 좋은 방법만은 아닙니다

이 모델에서는 위 그림처럼 5개의 브랜치가 사용됩니다

종류의미
master- 제품으로 출시될 수 있는 브랜치
정식 배포되는 안정 버전의 소스 코드/태그들이 포함되어 지난 버전을 빨리 확인가능
develop- 다음 출시 버전을 개발하는 브랜치
새로운 코드들이 계속 추가됨
pr(pull request)를 거친 코드들이 이곳으로 병합됨
feature- 기능을 개발하는 브랜치
새로운 기능 개발이나 버그 수정을 위한 코드 수정이 이뤄짐
혼자나 여러명이 작업한 내용이 pr을 거쳐 develop브랜치에 merge됨
release- 이번 출시 버전을 준비하는 브랜치
develop에서 만들어진 브랜치
배포를 위해 버그 수정이 이루어지고 develop에도 변경이 적용됨
이후 master에 병합되고 해당되는 태그(버전)가 생성
hotfix- 출시 버전에서 발생한 버그를 수정하는 브랜치
긴급하게 수정되어야하는 버그수정을 위한 브랜치
master에서 생성됨
  • support : 버전 호환성 문제를 위한 브랜치

Git Flow 개요

git-flow가 어떤 흐름으로 작업이 이루어지는지 알려면 아래 링크를 따라가면서 한번씩 해보는게 가장 좋은 것 같습니다

git-flow의 명령어들은 기존의 git 명령어들을 여러개 묶어서 만든 것이기 때문에 익숙해지려면 약간 시간이 필요합니다

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

그 과정을 대략적으로 정리하면 다음 과 같습니다

git-flow에서의 일반적인 작업 순서

  1. master 브랜치에서 init - 여러 branch들 기본설정
  2. feature 브랜치: develop 브랜치에서 feature 브랜치를 생성해 기능 개발
    2-1. feature publish/pull : 공동 개발을 위해 원격 저장소 업로드,가져오기
    2-2. feature finish : 검토를 거쳐서 feature 마무리
  3. release 브랜치: QA 단계 - 버그 수정과 기능검토
    3-1. release publish : 릴리즈 버전 공유를 위해 원격 저장소에 업로드,가져오기
    3-2. release finish : 결과가 develop브랜치와 master브랜치로 병합되고, master 브랜치에서 태그와 함께 배포된다
  4. hotfix : 릴리스 포인트와 상관없이 master에서 만들어 급한 버그를 수정한다

Git Flow 명령어

init

  • git flow init : git flow에 맞춰 저장소 초기화

-d : 기본값으로 설정

feature

  • git flow feature start 이름 : 새로운 feature branch 생성

생성 이후에 개발을 진행하게됩니다

  • git flow feature finish 이름 : feature가 완성되어 develop으로 병합한다

  • git flow feature publish 이름 : 원격 저장소에 push

gitflow 자체적인 pr(pull request)기능이 없기 때문에 github을 이용해 pr을 보내게 됩니다

  • git flow feature pull origin 이름 : 원격 저장소에서 내역을 가져옴

relaese

git flow relaese start 버전 : develop에서 relaese 브랜치가 생성

git flow relaese publish 버전 : 원격 저장소에 push
git flow relaese track 버전 (=pull) : 원격 저장소에서 변경사항 추적

git flow relaese finish 버전

git push --tags : 새로운 릴리즈가 포함된 master를 원격저장소에 태그와 함께 push함

hot fix

git flow hotfix start 버전
git flow hotfix finish 버전
git push --tags : 버그가 수정된 버전은 바로 master 브랜치로 들어갑니다

Fork/Git-flow 협업 과정 예시

팀장팀원
git flow init 명령어 실행
설정한 내역을 commit 후 원격에 push
깃헙의 프로젝트 설정을 통해 개개인 작업 할당해주기(auto kanban with reviews 옵션 사용)
깃헙issue에서 본인이 할 작업 밝힌 이후 fork
생성된 issue에 대해 세부 설정(담당, 프로젝트...)
fork한 저장소를 git clone
로컬에서 git flow init 후 feature 브랜치에서 작업
feature finish로 작업을 마무리
fork한 저장소로 commit / push
pr 요청(develop브랜치로)
이때 issue와 연결해서 요청 내용 작성(#1, #2...)
pr 처리(수정사항 이야기하기, 수락...)
수정 요청 반영(이 때는 feature를 만들지 않고 바로 develop에서 작업)
변경 내용 push
수정 내역 확인 및 approve -> merge
깃헙 프로젝트 해당 사항 완료 처리
현재 최신 진행 사항 반영
1. git fetch origin develop
2. git merge FETCHEAD
upstream 없을 경우 팀장의 저장소를 upstream으로 추가
git remote add upstream 팀장 주소
git fetch upstream develop으로 최신 결과 fetch
git merge FETCHEAD

git flow에서 프로젝트의 최신 진행 내역 가져오기

(git flow가 적용된 원본 저장소를 fork해서 작업하는 경우)

git flow에서 다른 사람들의 작업 내역을 반영해 최신 내역을 가져오는 것은 develop 브랜치를 update하는 것과 동일합니다

  • 팀장의 경우(원본 저장소 관리자)

git fetch upstream develop
git merge FETCH_HEAD

  • 팀원

git remote add pmorigin 원래 프로젝트 저장소
git fetch 원래 프로젝트 저장소 develop
git merge FETCH_HEAD

출처 및 참고

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html
https://uxgjs.tistory.com/183
https://techblog.woowahan.com/2553/

profile
프론트엔드 개발자 지망생

0개의 댓글