0C 개발일지
GitHub 협업 방식 Forking Workflow 사용 본문
학원에 들어와서 첫 팀프로젝트 진행할 때 처음으로 GitHub 을 사용했는데, 그때 엄청난 멘붕을 겪었다.
팀 내 전공자 분의 주도와 도움으로 하긴 했지만, 진짜 멘붕 엄청 오고 중간에 실수한지도 모르고 있다가 다음날 한소리 듣기도 했다.
굉장히 짜증나신 얼굴로 아침에 오자마자 나한테 머라머라 했는데, 그분이 새벽에 알아서 처리하시고 나서 말한거라 사실 지금도 정확한 이유를 모른다. 전날 내가 푸쉬했을 때는 문제 없이 올라갔어서 추측하기로는 어떤 경고 메시지가 떴을텐데 내가 못(안)보고 그냥 푸쉬해버린 게 아닐까 싶다.
그리고 문제가 발생할 때마다 매번 그 분에게 물어볼 수도 없으니 자바 코드를 짜도 모자랄 시간에 깃헙 문제로 하루를 날리기도 하고 잠은 잠대로 못자면서 열심히 하려고는 하는데 나아지는 건 없어서 이래저래 민폐만 끼치는 듯 하여 정말 고통스러웠다.
어쨌든 눈물의 똥꼬쇼를 하며 프로젝트를 마친지 불과 몇개월전.
두 번의 프로젝트가 끝나고 이제서야 깃헙이라는 존재가 조금은 익숙해지기 시작했다.
(오라클 프로젝트 때는 깃헙을 사용하지 않고, 팀원의 컴퓨터 1대를 서버로 사용했다.)
이번에 JSP, Servlet 수업 중 개별적으로 의견이 맞는 사람들끼리 토이 프로젝트를 진행하게 되었고,
팀원들과 상의해서 GitHub 협업 방식을 Forking Workflow 방식으로 사용하기로 했다.
해당 방식은 중앙 원격 저장소를 Fork해서 팀원마다 각자의 원격 저장소를 가지고 프로젝트를 진행하는 방식이다.
팀원은 각자의 저장소를 가지고 있어서 자유롭게 작업을 한 뒤, 중앙 원격 저장소를 Fork한 자신의 원격 저장소에 푸쉬한다. 그리고 본인의 작업 내용을 중앙 원격 저장소에 Pull Request 한다.
팀장은 팀원의 작업 내용을 확인한 뒤, 중앙 원격 저장소에 병합할지 안할지 결정한다. 다시 말해, 팀장이 코드를 확인후 머지하기 때문에 안전하게 협업이 가능하다.
첫 번째 프로젝트 때는 해당 방식의 안전장치가 없었기 때문에 서로 동시에 푸쉬해버리면 충돌이 나기도 하고 그랬다.
만약 그때 Forking 협업 방식을 알았더라면 그렇게 고생하진 않았을텐데 생각이 든다.
// 초기 설정
$ git clone 나의 Fork 주소
$ git remote -v // 확인
$ git remote add upstream 중앙 깃헙 주소
$ git remote -v
// 수정 사항
$ push git add .
$ git commit -m 메시지
$ git push origin main
나의 Fork 주소 에서 pull request -> new pull request
// 다른 팀원의 작업물을 가져오기
$ git fetch upstream fetch
$ git merge upstream/main
$ git push orign/main