안녕하세요 :> 지금까지 Git 알아보기 문서에서 Git 에 대한 기본적인 내용들을 얼추 다뤄보았죠!
그래서 이번에는 Git 으로 실전에서 어떻게 협업을 하는지를 알아보려고 합니다. 프로젝트가 수행되는 과정을 처음부터 끝까지 함께 살펴볼텐데요. 이번 글에서 프로젝트를 수행하는 개발자는 2명(A, B)이라 가정하겠습니다.
프로젝트 수행과정
수행 0. 기존에 Gitlab 을 이용해 A가 개발하고 있던 프로젝트에 B가 참여하기로 했습니다.
수행 1. 먼저 A 가 B 를 프로젝트에 초대해야겠죠. A는 Gitlab의 프로젝트 페이지 -> settings -> Members -> select members to invite 란에 B의 계정 혹은 이메일을 입력하고 Add to project 를 누릅니다.
수행 2. A는 해당 페이지의 하단 부분의 Existing members RacingGround 에서 프로젝트에 대해 B가 가지는 권한을 수정합니다.
Gitlab 에서는 프로젝트에 참여하는 권한에 대해 멤버 별 여러 등급으로 나누어 관리가 가능합니다.
디폴트값은 가장 낮은 등급인 Guest 인데요, 이 등급으로는 프로젝트에 제대로된 참여가 불가합니다. 프로젝트에 개발자로 참여하려면 최소한 Developer 로 권한을 수정해주어야 합니다.
참고로, A 의 등급인 maintainer 는 프로젝트에 대한 모든 권한을 갖고있는 최상위 등급을 말합니다.
* 잠깐! 알고가기 Fork 가 뭘까?
Git을 이용해 협업을 할 때, 크게 두 가지 방법론이 있습니다.
1. Git clone 을 통해 gitlab 서버의 프로젝트를 팀원의 컴퓨터로 복사해와서 코드를 작성하고, git push
이 방법은 기존에 저희가 알아보았던 방법이죠. 이 방법의 단점은, 개발자가 만든 소스코드가 바로 프로젝트의 소스코드에 병합된다는 것입니다. 한 명의 개발자가 만든 소스코드가 늘 완벽하기란 불가능 하지요. 그래서 이 방법은 실전에선 거의 사용되지 않습니다.
2. 원래 프로젝트(원본프젝)와 똑같은 프로젝트(복제프젝)를 gitlab 서버의 팀원의 계정 아래에 별도로 카피해 생성하기.
보통 실전에서는 이 방법을 사용합니다. 원본프젝을 복제해 복제프젝을 내 계정에 갖다두고, 복제프젝을 git clone 으로 내 컴퓨터에 가져온 다음, gitlab 서버의 복제프젝에 git push 를 하는 방법입니다. (주의 : 원본프젝에 push가 아닙니다)
이렇게 내 계정의 복제프젝에 업로드가 되면, 이후 원본 프젝에 merge request 를 합니다. merge request 란, 작업물이 완성되었으니 확인하고 이상이 없다면 우리 프로젝트에 반영해달라고 요청을 하는 것입니다. 이후 프로젝트의 관리자가 해당 merge request를 확인하고, 이상이 없다면 승인, 혹은 거절을 합니다.
자 그러면, 다시 프로젝트 수행과정으로 돌아갑시다.
수행 3. B는 지금까지 A 가 한 최신의 커밋을 가져오기 위해, 웹페이지의 프로젝트의 상단부에 있는 " Fork " 란을 누릅니다.
그러며 Fork Project 창이 뜨는데요, 누구의 계정에 Fork 할지 선택합니다. 이렇게 하면 원본프젝과 동일하지만 별개의 프로젝트인 나의 복제프젝이 생성됩니다.
수행 4. B는 생성된 내 계정의 복제프젝을 git clone으로 내려받고 확인합니다.
B가 하는 수행4의 세부 과정 예시는 이렇습니다. (VScode 터미널에서 실행한다고 가정)
- cd .\desktop\ : 바탕화면으로 이동
- mkdir {만들 폴더명] : 프로젝트 디렉토리를 넣을 폴더 생성
- cd {폴더명} : 생성한 폴더 안으로 들어가기
- git clone {복제용 프로젝트의 url} : B의 계정에서 gitlab 서버의 (복제)프로젝트를 받아옵니다. (복제프젝은 원본프젝에 비해 사용자 이름부분만 다릅니다.)
- 정보를 요구하는 창에 아이디와 암호를 입력합니다.
- ls : 해당 폴더에 잘 clone 되었는지 디렉토리를 확인합니다.
- cd {이동할 폴더명} : clone 한 프로젝트의 폴더로 들어갑니다.
- git log --all --graph : 지금까지 A가 만든 branch를 확인합니다.
수행 5. B는 커밋을 작성한 후, 자신의 계정의 복제 프젝에 올립니다.
- git checkout develop : master branch에 위치한 HEAD를 develop branch 로 옮깁니다.
- git config user.name {B의 이름} : 커밋을 누가하는지 기재해줍니다.
- git config user.email {B의 이메일} : 커밋한 사람의 연락처를 기재합니다.
<< B가 작업1 시행 >>
- git add . develop : develop branch의 staging area에 새로운 파일을 추가합니다.
- git commit -m {"파일1이름"} : staging area에 넣은 파일들을 커밋합니다. (develop branch에 커밋됩니다)
<< B가 작업2 시행 >>
- git add . : staging area에 새로운 파일을 추가합니다.
- git commit -m {"파일2 이름"} : staging area에 넣은 파일들을 커밋합니다.
- git push : gitlab의 B계정의 복제프젝에 지금까지 커밋한 내용을 반영합니다.(현재 헤드는 develop branch를 가리키고 있습니다. 자동으로 develop branch에 해당하는 신규 커밋들만 복제용 프젝에 업로드 됩니다. 여기서, 그 외의 것도 모두 업로드 하고싶다면 개별적으로 지정해줘야 합니다. 예를 들어, master branch도 업로드 하고싶다면 git push origin master 라고 하면 됩니다.)
수행6. B는 gitlab 서버에서 merge request를 요청합니다.
- gitlab의 복제프젝 페이지에 가서, Create merge request 버튼을 클릭해 요청합니다.
- 바로 뜨는 New merge project 창에서 Change branches 를 눌러 업로드할 branch를 변경합니다. 아래의 그림에 보이는 From ~ into ~ 를 확인하고 변경해주면 됩니다. 현재 원본프젝의 master branch로 되어있는데, develop으로 변경합니다.
- Title 과 Description 란에 지금껏 작성한 커밋에 대한 설명을 적습니다. merge request 를 적는 규칙은 회사마다 다릅니다. 이후 Assignee 를 설정해 내가 한 merge request 를 가장 먼저 점검할 담당자를 지정해줍니다. 이 경우 A를 지정해주면 되겠지요. (이후 나오는 Milestone 과 Labels 는 일단 넘어가겠습니다.)
- 페이지의 하단에서 신규 commit 들과 commit으로 인한 변경 사항을 확인하고 submit 합니다.
수행7. A는 gitlab 페이지에서 B가 보낸 request를 확인합니다. 커밋과 체인지에서 변경사항을 한눈에 확인할 수 있으며, merge request 에 대해 논의하고 싶다면 discussion 카테고리에 질문을 남기면 됩니다. 이후 B가 확인하고 답장을 해주겠죠?
수행8. A는 논의 및 검토가 끝난 후 Merge 버튼을 누릅니다. 원본 프로젝트를 확인하면, B가 올린 커밋들이 새롭게 업로드 된 것을 확인할 수 있습니다. B의 커밋과 함께, 새로운 커밋이 만들어진것도 확인할 수 있죠. 다른 복제본 프로젝트에서 보낸 매 Merge Request 마다 그에 대응되는 Merge commit이 생성되기 때문에, 우리는 정확한 이력을 파악할 수 있습니다.
MergeRequest 정책
여기서 한 가지 의문이 들 수 있는데요, B가 업로드 한 branch에 대해 Fast-Foward merge 를 하면 되는데, 왜 굳이 새로 커밋을 생성하였는가 하는 것입니다. Fast-forward 머지를 할 수 있는 경우에도 새 Merge Commit을 만들게 되면 커밋 히스토리의 가독성이 다소 떨어지게 되겠지요.
새로운 커밋을 생성할지, Fast-forward merge를 할지는 적용한 MergeRequest 정책에 따라 달라집니다.
gitlab 페이지의 settings 카테고리에 가면, MergeRequest 설정 부분을 확인할 수 있는데요.
위의 그림을 보면, 현재 merge commit 정책이 적용되어있는 것을 볼 수 있습니다.
Merge commit 정책은 어떤 경우라도 항상 merge를 할 때, 새로운 commit 을 생성하겠다는 것입니다.
맨 아래의 Fast-forward 정책을 선택하면, Fast-forward merge 가 가능할 때 새로운 commit을 생성하지 않고, 실제로 fast-forward merge 를 해줍니다. 이외 나머지 두 정책은 fast-forward 가 가능해도 항상 새로운 merge commit을 생성합니다.
더 알아보기
git push 를 해줄때, 내 commit이 gitlab의 원본 프로젝트를 포함하지 않는다면 push가 되지 않는다고 했었죠.
그러면, 그런거에 상관없이 지금까지 gitlab 서버에서 진행된 commit log 들을 내 컴퓨터에 있는 commit log로 몽땅 덮고 싶을땐 어떻게 해야할까요?
그런 경우엔 git push --force 명령어를 입력해 강제로 업로드를 해주면 됩니다. 이 명렁어는 내 commit이 gitlab 프로젝트의 commit을 다 포함하지 않더라도 무조건 push 해라 라는 명령어 입니다.
사실 이 명령어는 실무에서 절대 쓰지 않는다고 볼 수 있습니다. 만일 불가피하게 사용할때는 반드시 주의하시길 바랍니다.
오늘의 포스팅이 git을 이용해 협업해보려하는 초보 분들께 도움이 되었으면 좋겠네요.
다음 글에서는 기타 Merge 정책 이해, Git Rebase 해보기, Detached HEAD 이해하기 등의 내용을 다뤄보겠습니다.
감사합니다.