깃허브 협업 A to Z: 완벽 가이드

안녕하세요! 오늘은 개발자들 사이에서 필수적인 도구인 깃허브를 이용한 협업 방법에 대해 A부터 Z까지 자세히 알아보겠습니다. 이 글을 통해 여러분은 깃과 깃허브의 차이점부터 시작해 실제 팀 프로젝트에서 어떻게 협업을 진행하는지까지 배우실 수 있습니다.

1. 깃(Git)과 깃허브(GitHub)의 차이

많은 초보자들이 혼동하는 부분이 바로 깃과 깃허브의 차이입니다.

간단히 말해:

깃(Git): 여러분의 로컬 컴퓨터에서 버전 관리를 담당하는 시스템입니다.
깃허브(GitHub): 깃으로 관리하는 프로젝트를 온라인상에서 저장하고 공유할 수 있는 플랫폼입니다. 구글 드라이브와 비슷한 개념이라고 생각하시면 됩니다.

업로드의 다른 이름 PUSH

2. 기본 용어 정리

깃허브 협업을 이해하기 위해 알아야 할 중요한, 기본 용어들입니다:

Fork: 다른 사람의 저장소를 자신의 계정으로 복사하는 것
Upstream: (상유) 원본의 위치
Clone: 원격 저장소를 로컬 컴퓨터로 복사하는 것
Push: 로컬의 변경사항을 원격 저장소로 업로드하는 것
Pull: 원격 저장소의 변경사항을 로컬로 가져오는 것
Pull Request (PR): 자신의 변경사항을 원본 저장소에 반영해달라고 요청하는 것
Merge: 서로 다른 브랜치의 내용을 하나로 합치는 것
Conflict: 병합 과정에서 발생하는 충돌

3. 깃허브 협업의 기본 흐름

팀장의 역할:
프로젝트의 기본 세팅을 합니다.
GitHub에 새로운 저장소(Repository)를 만듭니다.
초기 코드를 push합니다.
팀원의 초대 - 그룹 프로젝트 구축하기
기본 셋팅부터 시작하기

팀원의 역할:

팀장의 저장소를 Fork합니다.
Fork한 저장소를 로컬에 Clone합니다.
로컬에서 개발 작업을 진행합니다.
팀원작업

작업 및 Pull Request:

팀원은 작업 후 자신의 Fork된 저장소에 Push합니다.

GitHub에서 팀장의 저장소로 Pull Request를 보냅니다.

4. 코드 리뷰 및 Merge과정:

팀장은 PR을 검토하고 필요시 코드 리뷰를 진행합니다.
문제가 없다면 Merge를 진행합니다.

팀원의 작업은 깃허브에서 이루어짐

만약 Able to Merge이면, Merge를 진행합니다.

5. Merge 완료

best cast-머지 완료

하지만, Conflict(Can't automatically merge)

4. 충돌(Conflict) 해결하기

가끔 Pull Request 과정에서 충돌이 발생할 수 있습니다.

이럴 때는:

다시 말해서, 팀원의 머지가 Conflict되면, 팀장님의 브랜치나, 팀장님의 래포를 받아와야합니다.(PULL) UPStreaming해서 팀장님의 풀을 받아옵니다.

팀원은 로컬에서 팀장의 최신 코드를 Pull 받습니다.

팀원의 git에서 모두해결되면 , 다시말해서 로컬에서 충돌이 모두 해결되면, 1.이 해결되었다고 말하는 것입니다.

로컬에서 충돌을 해결합니다.
해결된 코드를 다시 본인 래퍼(래퍼토리)에 올린다음(Push)하고 즉, 본인 브랜치에다 올린다음 PR(Pull Request)을 업데이트합니다.

5. 협업 시 주의사항

항상 작업 전 최신 코드를 Pull 받아오세요.
의미 있는 커밋 메시지를 작성하세요.
큰 변경사항은 새로운 브랜치를 만들어 작업하세요.
정기적으로 팀원들과 코드 리뷰를 진행하세요

마치며

깃허브를 이용한 협업은 처음에는 복잡해 보일 수 있지만, 이 기본적인 흐름을 이해하고 나면 매우 효율적인 협업 도구임을 깨닫게 될 것입니다. 실제 프로젝트에 적용해보며 경험을 쌓아가시기 바랍니다. 질문이나 추가 설명이 필요한 부분이 있다면 언제든 댓글로 남겨주세요!

행운을 빕니다, 그리고 즐거운 코딩 되세요!

도움주신분::https://www.youtube.com/watch?v=IT41djAKUgg

깃허브 협업 A to Z: 완벽 가이드