[Git/GitHub] 깃허브 Organization를 통해 체계적인 협업 문화를 만들어보자!

💋 인트로

 

팀 미션을 진행하던 도중, 우테코 백엔드 크루 주노로부터 Organization을 사용한다는 이야기를 들었다.

필자는 굉장한 정리벽이 있는 사람으로, 우리 팀의 결과물이 과정부터 차곡차곡 의미있는 형태로 모인다는 점이 정말 매력적이어서 곧바로 따라했다. 

어제 15분 동안 배웠는데, 오늘 포스팅을 할 수 있을 정도로 어렵지 않은 내용이다!

 

여기가 내가 만든 Organization의 링크이다!

starlight-shopping-order

 

 

이번 미션을 통해서 한 번 진행해보고, 어떤 점이 좋았는지에 대해서 회고로 포스팅할 예정!

 

이번 포스팅은 깃허브 Organization을 사용했을 경우에 협업이 어떤 방식으로 이루어지는 지에 대해서, 

작업 흐름의 순서대로 작성했다. 

 

 

 

 

 

✔ 해결하고자 하는 문제에 대해서 issue를 작성하자

 

 

먼저 하고자 하는 작업의 목적과 관련 기술, 완료 조건에 대한 내용을 포함한 issue를 작성한다.

 

 

 

 

과정을 통해서 팀원들에게 내가 어떤 내용을 구현하고자 하는지, 현재 어떤 일을 하고 있는 지 명확하게 전달할 수 있고, 앞으로 해야 할 일이 무엇인지에 대해서도 미리 작성해 놓을 수 있다. 상황에 따라 issue를 다른 팀원에게 assign할 수도 있어서, 책임도 명확히 할 수 있다.

 

 

여러 가지 issue를 작성하면 아래 사진과 같이 현재 우리 팀이 해결해야 할 일에 대해서 한 눈에 볼 수 있다.

 

 

close된 issue를 통해서 우리 팀이 이제까지 해결한 일들에 대해서도 볼 수 있다. 보면 기분이 그냥 좋다.

 

 

 

 

✔ 작성한 issue에 대해서, 로컬에서 구현하자!

 

organization에서, main 브랜치는 모든 큰 단위의 개발이 끝난 완전한 내용만 포함하기 위해서 별도로 develop 브랜치를 생성했다.

issue에 작성한 내용을 구현하기 위해서는 develop 브랜치에서 로컬로 pull, rebase을 한다.

 

로컬에서 관련 이슈와 관련된 이름의 브랜치를 만들어서 작업한다.

 

예를 들어서 logging과 관련된 작업을 하려고 한다면, feature/logging같은 이름을 사용할 수 있다. 이외에도 다양한 네이밍 컨벤션이 있다. feature/~ , bugfix/~, refactor/~처럼 브랜치도 체계적으로 관리하면 내가 어떤 작업을 하고 있는지에 대해서 더 명확히 순서를 정할 수 있다는 장점이 있다.

 

 

 

 

✔ 로컬에서 구현한 내용을 Pull Request 보내자!

 

로컬에서 구현을 하다가, issue에서 작성한 종료 조건이 충족되었다고 생각하면, 해당 브랜치에서 develop 브랜치로 Pull Request를 보낸다.

 

 

 

 

이때, 앞서 작성한 issue를 엮어서 함께 보낼 수 있다. 아래의 사진에서처럼 Development 설정에서 관련 issue를 선택하면 된다.

issue와 연관 지어서 Pull Reqeust를 보내게 되면 Pull Request가 merge될 때, issue도 함께 close 되기 때문에 굉장히 편리하고, 업데이트를 별도로 해주지 않아도 되어서 문서를 안정적으로 관리할 수 있다.

 

 

  

issue와 Pull Request 모두에서 Label을 통해서 feature, refactor인지 여부와 bugfix 등등을 표현할 수 있다. 

 

 

✔ Pull Request에 대해 코드 리뷰를 받고, 검토가 완료된 코드는 merge하자!

 

Pull Request에서 팀원들의 코드 리뷰를 받는다. 

이 때, 코드리뷰 컨벤션에 따라서 리뷰어는 의도를 명확히 드러낼 수 있다.

 

• Request Change: 적극적으로 반영을 고려해 주세요.
• Comment: 웬만하면 반영해 주세요.
• Approve: 반영해도 좋고, 넘어가도 좋은 사소한 의견입니다.

 

다른 팀원들의 검토가 끝났다면, 아래의 merge pull request를 통해서 변경 사항을 develop 브랜치에 합칠 수 있다.

 

 

 

 

✔ 위의 과정을 반복하며, 팀 전체의 코드를 쌓아 나가자!

 

아래 사진에서와 같이, 위의 과정이 반복되며 팀 전체가 동의한 내용대로 코드가 쌓여나간다. 뿌듯하고 체계적이다.

 

 

develop 브랜치에 merge된 내용이 있다면, 다음 Pull Request를 보내는 팀원은 자신의 커밋과 develop의 현재 커밋이 충돌하지 않도록 작업 전에 git pull, git rebase을 통해서 내 로컬의 코드가 upstream과 잘 동기화 되어 있는지 수시로 체크하는 과정이 필요할 것이다. 

 

issue와 함께 즐거운 프로그래밍! 

 

---

 

끗

 

이 글이 도움이 되었다면 좋아요와 댓글 달아주세요!