이 문서는 5인으로 구성된 소규모 팀이 깃헙을 협업도구로써 잘 활용하는 방법에 대해서 공부해서 정리했습니다. 실제 팀원들이 이 문서를 활용해서 협업에 활용할 수 있도록 메뉴얼 형식으로 작성되었습니다.
한 개의 프로젝트에 여러 명이 코드를 작성하다보면 당연히 나의 코드를 다른 사람이 수정할 수 있고 다른 사람이 수정한 코드가 내가 짠 코드와 맞지 않는 문제가 발생할 여지가 매우 크다. 그래서 깃헙을 사용해서 그러한 충돌을 최소화하고 이를 통해 팀원들과 원활한 의사소통을 하는 것이 생산성에 매우 중요하다.
다른 사람이 짠 코드와 충돌을 막기 위해서 깃에서 제공하는 branch 라는 것을 활용하는데 기본적으로 본인이 구현할 기능별로 branch 를 만들어서 프로젝트를 진행할 것이다.
위 이미지에서는 develop 브랜치가 따로 있지만 이번 프로젝트에서는 master 브랜치가 따로 있고 각자 본인이 맡은 기능별로 branch를 만들어서 기능 구현이 완료되면 master 브랜치에 pull request 를 보내서 merge하는 방식으로 진행할 것이다.
이제부터 ft_transcendence 프로젝트 팀에서 따라야 할 협업 방식에 대해서 설명하겠습니다.
- 우선 프로젝트 저장소를
clone합니다.
git clone [git repo]- 본인이 맡은 기능의 간단한 이름을 정해서 브랜치를 만듭니다.
git branch // 현재 로컬 저장소에 있는 브랜치 목록을 불러옵니다.
git branch navbar //navbar 기능을 구현할 브랜치 이름으로 브랜치 생성
git checkout navbar //navbar 브랜치로 이동하기
//위 두 줄의 코드를 한 번에 하려면
git checkout -b navbar //navbar라는 브랜치를 만들면서 동시에 이동하기- 코드를 작성합니다. 그런데 여기서 다른 컴퓨터에서 작업하기 위해 그 날 짠 코드를 깃헙 저장소에 저장하고 싶을 수 있습니다. 그럴 때는 현재까지 짠 코드를 commit 하고 해당 브랜치에 push 를 해줘도 무방합니다
주의! 여기서 master에 push를 해버리면 절대 안 됩니다!
하지만 push를 못하게 막아놨기 때문에 어차피 안 될 것입니다.
git add .
git commit
git push origin navbar- 이전에 작성한 코드가 깃헙 저장소에 해당 브랜치로 저장돼있으니 이어서 작업을 하고 싶을 때(예를 들어 다른 노트북으로 작업을 이어하고 싶을 때)는 본인의 브랜치를 pull 받아 계속해서 작업을 진행합니다.
git pull origin navbar- 기능 구현이 완료됐을 시 pull request를 보내서 다른 팀원들에게 코드 리뷰를 받고 문제가 없다면 master 브랜치에 merge를 합니다.
위 이미지에서 좌측 상단 Pull requests탭을 클릭한 후에 New pull request버튼을 누르면 위와 같은 화면이 나옵니다. 중간에 브랜치를 선택하는 화면에서 본인의 브랜치를 선택해서 main <- navbar 가 되도록 합니다.
- 해당 pull request 에 대한 제목을 정하고 상세 사항을
Leave a comment부분에 작성합니다. 그 후에 중요한 점은 우측에 표시한 부분입니다. - Reviewers, Assigness 에는 해당 코드를 리뷰하기를 원하는 팀원의 아이디를 선택해줍니다(중복 가능). 이번 프로젝트의 경우에는 백엔드는 백엔드, 프론트엔드는 프론트엔드 팀원을 추가합니다.
- Label은 중복선택이 가능하니 해당 PR에 포함되는 모든 라벨을 선택합니다.
- Project는 하나밖에 없으니 ft_transcendence 를 꼭!! 선택합니다.
- Linked issue는 연결해줘야 하는 issue 가 있을 경우 꼭 연결을 해줘야 하는데 일단은 그대로 둔 상태로 진행합니다.
- 우측에 있는 Create pull request 버튼을 누르면 pull request 가 생성됩니다.
- 이제 PR을 생성한 이후에 Linked issue 를 눌러서 해당 이슈를 연결해줍니다. 이렇게 하면 프로젝트 칸반보드에 풀리퀘스트와 함께 적절한 칼럼으로 같이 이동하도록 설정을 해놔서 따로 관리를 할 필요 없이 이슈가 done 칼럼으로 PR과 함께 이동하면서 가시적으로 도움이 될 것입니다.
이렇게 PR을 생성하면 다른 팀원들에게 메일로 알람이 갑니다. 그러면 다른 팀원들은 변경된 코드를 확인하고 코멘트를 달아서 의견을 게시합니다.
다음은 다른 팀원이 코멘트를 달고 PR을 승인하거나 거절하는 상황입니다.
위 이미지에서 표시한 Add your review 버튼을 눌러서 코드리뷰를 시작합니다.
코멘트를 달고 싶은 코드 부분을 드래그해서 선택하고 작성하면 됩니다.
코멘트를 다 작성하고 난 후에 우측 상단에 있는 Review changes 를 클릭합니다.
단지 코멘트만 달고 싶을 때는 Comment 를 클릭해서 리뷰를 남기면 됩니다.
5-1. 코드에서 문제점을 발견했을 경우(PR 거절)
Request changes 를 선택하고 Submit review 를 클릭합니다.
팀원이 이렇게 PR을 거절하면 PR을 올린 사람이 코드 리뷰를 확인할 때 거절당한 것을 알 수 있습니다. 그러면 PR을 생성한 사람이 코멘트를 참고해서 자신의 코드를 수정하고 다시 git push 를 하면 해당 PR이 살아있는 상태에서 commit이 추가가 됩니다. 그러면 PR을 거절한 팀원이 새로운 커밋을 확인하고 승인을 해주면 됩니다.
여기서 바로 approve 를 하면서 comment를 남기면 이에 대해서 PR을 생성한 팀원이 추가적인 코멘트를 달 수 없으니 서로 코멘트를 통한 충분한 리뷰 이후에 완전히 납득하고 최종적으로 approve를 해줘야 합니다.
5-2. 정상적인 코드라고 판단했을 경우(PR 승인)
Approve 를 선택하고 Submit review 를 클릭합니다.
- PR이 정상적으로 승인이 되면 PR을 올린 본인이 직접 merge를
진행합니다.
이 부분은 사실 아무나 merge 할 수 있지만 본인이 직접 하는 것을 우리 팀의 원칙으로 정하고자 합니다.
이 때 Squash and merge를 선택해서 merge를 하면 master 브랜치에 해당 코드(새로 구현한 기능)가 추가됩니다.
Squash and merge를 하는 이유는 그 기능을 완성하는데 여러 커밋메세지들이 쌓일텐데 그 부분을 하나로 묶어줘서 PR 단위로 커밋로그를 새로 만들 수 있기 때문입니다. 커밋내용을 여기서 상세하게 다시 종합해서 적어주면 더 좋은 commit log 가 쌓일 것 같습니다.
-
본인이 직접 merge를 하면
delete branch버튼이 활성화됩니다. 이 버튼을 눌러서 기능개발이 완료된 branch를 삭제해서 더 깔끔한 상태로 유지합시다. -
이렇게 PR이 master 브랜치에 merge가 되면 다른 팀원들은 작업중인 본인의 로컬 컴퓨터에서 master branch를 최신화 해줘야 합니다.
//<본인의 로컬 컴퓨터에서 본인의 브랜치에서 작업을 하는 상황>
git checkout master //master 브랜치로 이동
git pull origin master //PR 이 merge 됐기 때문에 master브랜치를 새로 가져옴
git checkout mainpage //본인이 작업하던 본인 브랜치로 이동
git merge master //본인 로컬 컴퓨터에 최신화된 master 브랜치를 개인 브랜치로 가져옴이 방식이 기본적으로 팀에서 협업도구로써 깃헙을 활용하는 방법입니다.
추가적으로 깃헙에서 해당 기능에 대해서 issue를 발급하고 그 이슈에 대해서 본인이 작업하고 있는 것을 다른 팀원들에게 가시적으로 보여줄 수 있습니다. 그래서 원칙적으로 어떤 기능을 맡아서 개발할 때는 해당 issue가 생성돼있지 않다면 본인이 직접 issue를 발행해서 PR과 연결하여 개발을 진행해주시면 됩니다.
다른 사람들은 issue를 자유롭게 발행해서 다른 이러이러한 일을 해야 한다는 것을 모든 팀원들에게 보여줄 수 있습니다. 이렇게 우리 팀이 진행해야 할 과제들에 대해서 서로 공유가 될 수 있고 어떤 팀원이 어떤 개발을 하고 있는지를 깃헙 Project 탭에서 확인할 수 있습니다.
물론 위 이미지는 테스트용이기 때문에 issue 제목 등은 명확해야 합니다. 참고용으로만 봐주시면 됩니다ㅎㅎ
