1. 개요
프로그래밍을 공부하고 있는 입장으로서 GitHub으로 인한 협업은 피할 수 없는 과정이라고 생각된다.
그러나 나를 포함한 Git 사용 초심자들은 그저 add, commit, push만 반복하다 원리도 모른채 잔디밭만 채우기 일수다.
그래서 오늘은 기본적인 요소를 넘어 Fork부터 Pull Request까지의 과정을 정리해 보려 한다.
앞서 협업을 언급했지만 사실 여기서 설명하는 내용만으로는 여러사람들과 함께 협업을 하는 전체적인 과정을 이해하기에 부족하다.
설명하기 앞서 이 과정은 단순히 저장소를 가져와 추가 및 수정을 하고 다시 올리는 과정이며 새발의 피라고 볼 수 있다.
협업을 위한 더 깊은 내용은 앞으로 공부하여 차차 다뤄볼 것이다.
2. Fork ~ Pull Request까지의 과정
생소한 단어가 보일 수 있지만 중간 중간 쉽게 설명할 것이니, 우선 과정을 익히는데 중점을 두자.
2.1. Repository
GitHub을 사용해 봤다면 필히 접해봤을 것이다. 바로 '저장소(Repository)'이다.
말 그대로 저장을 하는 공간 이라고 이해하면 쉽다.
이번 과정에선 총 세가지 Repository를 통해 진행할 것이다.
-
Origin Repository : 우리가 받아와 내용을 추가하거나 수정할 '원본 저장소'이다.
주로 Organization의 저장소나 프로젝트를 진행하는 사람의 개인 저장소 등 프로젝트를 대표하는 저장소라고 생각하면 된다. -
Forked Repository : 사용자 개인의 '원격 저장소'이다.
GitHub에서 로그인하여 개인의 저장소를 관리할텐데 바로 그 공간이라고 생각하면 된다.본문에서는 원격 저장소와 개인 저장소를 같은 의미로 사용한다. -
Local Repository : 우리의 데스크탑, 즉 '로컬 저장소'이다.
주로 Visual Code나 intelliJ에서 작업을 할텐데 바로 그 작업하는 공간이라고 생각하면 된다.
2.2. Fork
원본 저장소, 즉 대표 저장소가 있다면 우선 나의 독립적인 공간으로 가져와 보자.
이 때 사용하는 것이 바로 'Fork'이다.
Fork를 한다는 것은 원본 저장소를 복사해 와서 독립적인 개인 저장소를 만들겠다는 의미이다.
독립적인 개인 공간이기 때문에 Forked Repository를 건든다고 해서 원본 저장소가 변경되는 일은 없다.
위 사진과 같이 Fork를 할려고하는 저장소에 들어가면 우측 상단에 대놓고 있다.
해당 버튼을 누르면 '본인 깃헙 아이디/저장소 이름'이라는 이름의 저장소가 개인 저장소로 생성된 것을 확인 할 수 있다.
여담으로 원본 저장소를 바로 git clone하면 되는 것 아니냐 라는 의견도 꽤 많다.
과정 상 큰 문제는 없지만 Fork를 사용하는 가장 큰 이유는 아무래도 '안정성'이라고 생각한다.
과정 중 단계가 많을 수록 그만큼 백업할 수 있는 공간이 많다는 의미이니,,
결국 안정성과 편리함은 반비례가 아닐까?2.3. Clone
개인 저장소를 만들었다면 내 작업 공간으로 불러와 보자.
add, commit, push를 이미 해봤다면 이정도는 어렵지 않게 할 수 있을 것이다.
생성한 개인 저장소에서 우측 상단 'Code'를 눌러 주소를 복사한다.
그 후에 자신이 원하는 디렉터리(폴더)로 이동하며 터미널(cmd)를 켜 다음 명령어를 입력한다.
git clone '복사한 저장소 주소'본인의 로컬에 해당 저장소 디렉터리가 생성되는 것을 확인 할 수 있다.
2.4. Branch
작업할 공간까지 만들었다면 브랜치를 생성해 보자. 브랜치란 master(or main) 브랜치가 아닌 '또 다른 작업 공간'이라고 볼 수 있다.
지금까지 원본 저장소에서 Fork를 통해 독립적인 개인 저장소를 생성한 것처럼 작업 공간에서도 브랜치를 생성하여 독립적인 작업 공간을 생성한다.
따로 브랜치를 만드는 이유는 여려명이서 하나의 파일을 대상으로 작업 하는 것보다 각자의 브랜치에서 작업 후에 합치는 것이 안전한 방법이기 때문이다.
이미 개인 작업 공간인데 왜 따로 브랜치를 만드냐고 의문이 들 수 있다.
그 점은 후에 원본 저장소에 추가 & 수정한 내용을 올릴 때 설명하겠다.branch 생성 명령어는 다음과 같다.
// 첫번 째 방법
git branch '생성할 브랜치 이름'
// 두번 째 방법
git checkout -b '생성할 브랜치 이름'첫번 째 방법과 두번 째 방법의 차이는 HEAD를 어디에 두드냐의 차이다.
첫번 째는 단순 브랜치만 생성, 두번 째는 브랜치를 생성함과 동시에 생성된 브랜치로 HEAD가 이동한다.
HEAD란 포인터 같은 개념이다.
HEAD가 main 브랜치에 있다면 main 브랜치에서 작업하겠다는 의미이다.첫번 째 방법으로 브랜치를 생성했다면 작업하기 전 다음과 같은 명령어로 HEAD를 이동하자
git checkout '생성한 브랜치 이름'+) 생성 브랜치 이름으로는 주로 develop이나 feature이 쓰인다.
git branch convention을 참고하자.2.5. Add & Commit
작업을 할 branch를 생성했다면 코드를 추가 및 수정하고 add & commit을 진행하자.
명령어는 다음과 같다.
// add
git add . // 변경한 전체 파일을 추가할 때
git add '추가할 파일 이름' // 특정 파일만 추가하고 싶을 때
// commit
git commit -m "추가한 파일의 내용"add & commit을 한다고 해서 내 개인 저장소에 영향이 가지 않는다.
add & commit을 하면 Index 공간에 이동하게 되는데 쉽게 설명하자면
add는 물품을 보내기 위해 포장을 하는 것이고, commit은 포장된 박스에 어떤 물품인지 라벨을 붙이고 보낼 준비를 하는 것이다.
2.6. Push
add & commit을 통해 보낼 준비가 됐다면 push로 원격 저장소에 보내보자.
단 여기서 평소에 하던대로 'git push'만 입력해서는 안된다.
우리는 따로 branch를 생성하였고 나의 개인적인 branch를 다른 사람의 작업과 겹치지 않게 그대로 올릴 것이기 때문에 다음과 같은 명령어를 입력한다.
git push origin '작업 중인 branch 이름'그렇다면 평소 처럼 원격 저장소의 main 브랜치로 병합되는 것이 아닌, 새로운 branch가 생성되어 내가 추가 & 수정한 코드가 따로 존재할 것이다.
4번 branch 항목에서 왜 브랜치를 만드는지 이유가 되는 부분이다.
이런식으로 원본 저장소에 가는 중에서도 기존 코드는 건들이지 않고 생성한 브랜치 그 자체를 보내는 식이다.
사진과 같이 브랜츠 드롭다운 버튼을 클릭하면 내가 생성한 브랜치가 있는 것을 확인 할 수 있다.
+) 그래프를 보면 push를 하는 시점보다 먼저 브랜치가 생성된 것처럼 보이지만,
로컬에서 브랜치를 생성하고 push를 해주어야 동시에 원격 저장소에도 branch가 생긴다.2.7. Pull Request & Merge
개인 저장소에도 내가 추가 & 수정한 파일의 브랜치를 생성했다면 이제 원본 저장소에 올려보자.
우선 바로 위 사진의 개인 저장소에서 브랜치를 확인하는 부분에서 내가 생성한 브랜치(사진에서는 test)를 클릭하여 변경하자.
변경하면 우측에 'New Pull Request'가 바로 보일 것이다. '원격 저장소로 보낼래?' 라는 의미이다.
위 사진을 보면 짐작을 할 수 있겠지만 Pull Request는 원격 저장소에 저장하는 기능이 아니다.
Pull Request는 원본 저장소를 관리하는 사람에게 내가 만진 코드를 보낼 테니 한번 검토해달라 라는 뜻이다.
실제로 pull request를 보낼 때 '리뷰어'를 설정할 수 있다.그 뒤로 원본 저장소를 관리하는 사람이 해당 코드가 문제 없음을 확인한다면 마지막 단계인 'Merge'를 통해 병합할 것이다.
3. 결론
결론적으로 크게 아래의 다섯가지 단계를 따른다.
- Fork
- Clone
- Branch 생성
- Add & Commit & Push
- Pull Request & Merge
개요에 다음과 같은 과정이 새발의 피라고 한 이유는
협업을 함에 있어서 위 내용과 같이 기존 코드를 수정하고 올리는 것 뿐만 아니라, 수정된 코드를 받아보고, 그에 따른 코드 충돌을 해결하기도, 리뷰하기도 하는 등 다양한 과정이 속해있기 때문이다.
아직은 미숙하지만 git에 대해 학습하여 앞으로 현업에 나가서도 문제없이 협업할 수 있는 개발자가 되야겠다.
4. 마무리
항상 git clone을 통해서만 프로젝트를 해왔던 나에게 fork를 해야 할 기회가 생겨 조금의 공부를 하게 되었다.
나중에 git에 대한 이해도가 높아지고 본문의 내용 중 틀린 내용을 발견할 것을 생각하면 벌써 창피하기도 하고 내심 기대가 되기도 한다.
잘못된 점에 대한 지적과 조언은 언제든 환영입니다.
