깃허브 협업 방식 정리

[ 용어 정의 ]

레파지토리 = 내 원격 레파지토리 = 원격 저장소 = 내 깃허브 계정의 원격 저장소 = 내 레포
→ (외부)원본 저장소를 포크(Fork) 하면 생성되는, 내 GitHub 계정에 속한 원격 저장소.
→ 원본 저장소와 별개로 존재하지만, 원본 저장소의 변경 사항을 가져올 수 있음.

    (그러면서도 내 계정에 속하기 때문에 자유롭게 수정할 수 있음)

→ 내 계정에서 수정 후, 원본 저장소에 Pull Request를 보낼 때 사용.
→ 협업자가 아닌 외부 기여자가 기여할 때 주로 사용됨.

 

→또는 내가 원본 저장소에 멤버로 속해있거나 내가 만든 레포인 경우, 내 GitHib계정에 속한 원격 저장소.

 

원본 저장소 = 원본 레파지토리 = 외부 원본 레포 = 원본 저장소
→ 팀에서 사용하는 공식적인 GitHub 저장소.
→ 원격(remote) 서버에 존재하며, 모든 협업자들이 공유하는 저장소.
→ 일반적으로 origin 혹은 upstream으로 설정됨.

(이 글에서는 원본 레파지토리라는 것은 외부의 내가 속하지 않은 팀의 레파지토리라는 의미)

 

내 컴퓨터 = 로컬 저장소
→ git clone 명령을 사용하여 원격 저장소에서 복사해온 로컬 환경의 저장소.
→ 내 컴퓨터에 존재하는 Git 저장소로, 커밋(commit)이나 브랜치(branch) 생성 등의 작업을 수행하는 공간.
→ git add, git commit, git push 등의 명령어를 사용하여 변경 사항을 관리하고 원격 저장소에 반영함.

 

[내가 특정 프로젝트에 중도참여 & 일시적 도움을 주게 될 때는 0번부터 시작(or 오픈소스 기여)] 

 

0. 원본 저장소를 fork 해온다

fork 를 사용해서 원본 저장소의 코드를 나의 저장소로 가지고 오자

즉 내 원격저장소에 원본 저장소 레파지토리를 복사해오는 것

이 복사본을 수정 변경하여 pull request 를 날릴 것이다. 

• 오가니제이션(Organization) 내에서 member로 속해있어 쓰기 권한(push 권한)이 있는 경우에는 필요 없다.
• 주로 외부 기여자이거나 원본 저장소에 직접 푸시 권한이 없는 경우 Fork를 사용한다.
• Fork는 원본 저장소를 내 GitHub 계정의 저장소로 복사해오는 과정이다.
• 복사한 내 저장소에서 수정 및 변경 작업을 진행하고, Pull Request를 통해 원본 저장소에 기여할 수 있다.
• 이 경우, 아래 1번의 "레파지토리"는 "내 원격 레파지토리"를 의미한다

 

[일반적으로 오가니제이션에 멤버로 속해있으며, 레포 파서 팀내 협업하는 방식은 1번부터 시작]

 

1. 레파지토리 url을 내 컴퓨터(=로컬 저장소)에 clone 해온다 (내 원격 저장소의 코드를 내 컴퓨터로 복사해온다 _ 개발을 위해)

git clone 레파지토리url

-> 이때 레파지토리에서 모든 브랜치를 가져오는게 아닌 main 브랜치만 clone해오게 됨

= 원격 저장소(레파지토리 main 브랜치의 저장소)와 로컬 저장소(origin = 내 컴퓨터 저장소)가 연결되었다 

 

레파지토리 : 내가 쓰기 권한을 가진 팀에서의 "원격 레포" or 내가 남의 저장소를 내 깃허브 저장소에 fork해온 "내 원격 레포"

 

 

2. fork 해온 원본 저장소를 remote 저장소에 등록해준다

1에서 clone 해온 url은 origin 이라는 이름으로 내 원격 저장소에 자동 지정된다. (=내 컴퓨터에다 upstream을 등록해두는 것)

그러나 0에서 fork 해온 원본 저장소는 자동 지정이 안되기 때문에 직접 지정해주는게 좋다고한다.

git remote add 별명 원본-저장소-url

 

이 원본 저장소를 remote 로 등록해두면 추후에 원본저장소와 로컬 코드를 동기화 시킬때 [git pull 별명] 의 형식으로 사용하게 된다.

 

 

3. 로컬 브랜치를 생성해준다 (내가 로컬에서 작업할 공간)

본인이 컴퓨터(로컬)에서 코드 작성하고 깃허브에 올려야 하는데 이걸 바로 main 브랜치에 올리는게(git push 하는거) 아니라 서브 브랜치를 파서 거기에 먼저 올리고 그 뒤에 PR 날리고 머지한 후에 문제 없음을 확인한 후 main 브랜치에서 코드 동기화 시킬 것임

 

그러기 위해서 로컬에서 main이 아닌 dev 또는 test 등의 서브 브랜치 생성해주면 원격 저장소에도 해당 브랜치가 생성된다.

이렇게 브랜치 분기를 만들어 작업해야한다.

(브랜치 분기 = main 에서 test 브랜치가 파생되는 것)

 

왜 브랜치 분기가 협업에서 중요한가?

분기를 나누고 작업한다고 할 때,

(test 브랜치의)새로운 변경사항이 기존의 main 브랜치와 충돌을 일으킨다면 아직 main 브랜치와 test 브랜치가 나누어져 있으므로 test 브랜치만 없애주어 이전 코드로 쉽게 되돌릴 수 있기 때문이다. main은 배포환경에서 문제없이 구동될 수 있는 상태로 유지되어야한다. 

 

브랜치 생성과 전환

git checkout -b test

-> 이렇게 하면 test 라는 브랜치를 생성함과 동시에 현재 연결된 main 브랜치에서 test 브랜치로 브랜치 전환이 발생한다. 

= test 브랜치 내에서 작업을 하고, test라는 이름의 원격 저장소를 만들어 내가 쓴 코드를 올릴 수 있게 된다 (push할 수 있다)

 

브랜치 생성만 하기 (여전히 원래 브랜치에서 작업을 진행하게 됨)

git branch test  

 

 

4. add-commit-push 으로 test 브랜치(내 원격 저장소)에 본인 작업 내용을 올린다.

 

test 브랜치 (로컬 저장소)에서 작업하던것을 git push origin test 를 통해서 test 브랜치 (원격 저장소)로 올린다.

=> 원격저장소는 기존의 main 브랜치 한 줄에서 test 브랜치가 파생된 상태 

 

 

5. 깃허브 레파지토리(내 저장소)에 들어가보면 Compare & pull request 버튼이 생겨났을 것이다. 그 버튼을 눌러서 pull request(pr) 를 보낸다. (협업자 등에게)

pr은

현재 레포의 test 브랜치 -> 현재 레포의 main 브랜치로 지금 변경한 코드 merge를 요청하거나 

(fork한 경우)현재 레포의 test 브랜치 -> 원본 레포의 main브랜치로 지금 변경한 코드 merge를 요청하거나 

 

제목과 내용을 작성하고 우측 하단의 create pull request 버튼을 누르면 된다.

이때 기존과의 변경사항이 잘 드러나게 글을 작성한다. 

 

6. pr을 받은 협업자 or 관리자 가 코드를 검토한다. 그리고 merge 여부(or reject)를 결정한다

merge

• 원본 저장소(= 원격 저장소의 main 브랜치)에 pr 들어온 코드를 기존의 코드와 합친다. => pr 의 상태는 closed 되고 원격저장소 브랜치는 다시 main 한 줄이 된다. (test 브랜치가 main 브랜치에서 파생되어 나온 뒤 다시 들어간다는 개념)

reject

• pr 들어온 코드를 합치지 않는다.

 

7. 원격저장소 main 브랜치의 상태를 로컬저장소 main 브랜치에 가져와준다 (동기화 한다)

git pull main

원격저장소 main 브랜치는 test 브랜치와 합쳐지는 작업 등이 적용되어 업데이트 된 상태이다.

그런데 로컬에서는 test 에서 작업했으니 로컬 main 브랜치는 업데이트가 안된 상태이다. 

 

추가로 동기화를 해주어야 로컬의 main 브랜치가 업데이트 된다.

 

 

8. 로컬에서 코드 작성을 위해 만들었던 test 브랜치를 삭제한다 

git branch -d test

작업하던 로컬 브랜치는 더이상 사용되지 않으므로 삭제한다. 

예를 들어 알림 오류 해결을 위해 작업을 시작했다면 관련 이름으로 브랜치명을 짓고 오류 해결 후에는 브랜치를 삭제하는 느낌이다.

 

 

+)  추가 작업 필요한 경우

 

다시 추가로 작업을 해야할 때는 git pull main 으로 원격저장소와 로컬 저장소 내용을 동기화 시켜주고 

새로운 로컬 브랜치를 만들어서 2-7 과정을 반복해주면 된다.