Github
로컬A가 작업물(파일)을 깃헙의 원격저장소에 업로드합니다(Push)
로컬B가 그것을 내려받습니다(Clone)
각자가 작업을 진행한 뒤
로컬A가 업데이트한 파일(버전2)을 푸시하면
로컬B가 그것(버전2)을 넘겨받아(Pull) 본인의 작업물과 병합(버전3)하여 다시 푸시합니다
...
이러한 프로젝트 진행 방식은 풀과 푸시 과정 사이에 비는 시간이 생기는 만큼
팀 작업의 효율성도 떨어지고, 기껏 작업한 결과물이 깃헙의 메인 브랜치와
충돌이 발생하기도 쉽습니다
이러한 코드 충돌의 위험성을 줄이기 위해
깃헙에서는 '풀리퀘스트(Pull Request)'라는 기능을 제공하고 있는데요
먼저 풀리퀘스트를 통합 협업은 다음과 같은 과정을 거칩니다
1. Pull Request & Fork
- Pull Request
1) 로컬A(팀장)이 먼저 작업물(메인 브랜치)을 저장소에 올립니다
2) 로컬B가 로컬A의 원격저장소를 포크(Fork)합니다
3) 로컬B가 로컬A의 메인 브랜치를 클론으로 내려받아
코드를 수정 & 추가한 뒤 로컬A의 깃헙(원격저장소)에 푸시합니다
4) github에서 로컬A에게 풀리퀘스트 메세지를 전송합니다
5) 로컬A(혹은 권한을 부여받는 로컬B)는 여기서 제안받은 커밋 내용을 검토하고,
깃헙에 저장된 메인 브랜치와 합칠 것인지 거절할 것인지를 결정합니다
- Fork?
Fork란 타인의 원격 저장소를 통째로
본인의 Github 계정(원격 저장소)에 복사해오는 기능입니다
이 기능을 통해 저장소를 본인의 계정에 가져오면 그것을 로컬저장소에 내려받고(Clone)
코드를 수정한 후 코드의 제작자에게 풀 리퀘스트를 보낼 수 있게 됩니다
그 뿐만 아니라 본인 스스로에게도 풀리퀘스트를 보내고 머지 작업을 진행한 뒤
자신만의 버전을 만들어서 이어나갈 수도 있습니다
(오픈소스...)
풀리퀘스트를 통한 협업에는 여러가지 장점이 있습니다
-
로컬에서 추가한 코드의 구동여부를 확인하고,
사이트에서 한번 더 머지 검증절차를 거친다는 것 -
불필요한 커밋 히스토리를 남기지 않는다는 것
-
푸시 권한이 없는 프로젝트에도 내가 만든 코드를 제안할 수 있다는 것
본인의 작업물은 본인이 책임을 지고 머지 작업을 진행하며,
충돌이 나지않게끔 작업용 브랜치를 따로 분리해서
메인 브랜치는 최대한 건들지 않게끔 하는 것이 베스트입니다
그리고 원격 저장소의 브랜치 병합 과정이 모두 끝나면
작업에 사용한 브랜치를 삭제하고 새로운 브랜치를 만들어서
작업을 진행하는 것을 추천합니다
( 중요한 포인트는 브랜치를 작은 단위로 만드는데 있습니다
브랜치를 길게 유지하게 되면 메인 브랜치와 차이가 커져
나중에 코드를 합치기 쉽지 않아요)
2. github.io
"github 유저네임"/github.io github.io를 제작합니다
github.io는 별도의 도메인을 구매하지 않아도
사용자가 올린 코드를 바탕으로 사이트와
도메인을 만들어주는 유용한 기능을 합니다
(github 계정당 하나씩만 만들 수 있습니다)
작업을 마친 메인 브랜치를
git push https://github.com/유저네임/유저네임.github.io main
위와 같은 형태로 푸시를 진행합니다
github.io는 자신만의 포트폴리오 사이트 제작에
이용하기에도 유용합니다
다만 업데이트 반영속도가 다소 느린 편이니 (5분에서 10분)
라이브서버로 먼저 확인을 한 다음 푸시를 진행하는 것이 좋습니다
3. 그 밖의 주요 기능
README.md
README.md 파일은 미리 만들어서 업로드할 수도,
아니면 깃헙 페이지에서 만들어서 끼워넣을 수도 있습니다
이 안에는 코드에 대한 소개, 팀 구성도, 워크플로우,
업데이트 내역(버전) 등의 정보를 담는 것이 보통이지만
그날의 회고를 담아 데일리 로그로써 활용할 수도 있습니다
작업이 막바지에 다다르면 항상 README 파일을
같이 정리해서 올리는 습관을 들입시다
Issues
이슈탭은 일종의 커뮤니티 기능을 합니다
마찬가지로 글 작성시 마크다운 문법을 사용할 수 있고,
어떠한 이슈가 생겼는지에 대해 태그를 달 수도 있습니다.
