[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 16차 - 깃허브 그룹 프로젝트(이슈 생성, 커밋, 풀 리퀘스트)

📚 서론

과거 제가 깃을 활용하던 방법은 브런치명을 추가하려는 기능명으로 만들어서

완성되면 main에 Merge 하는 식의 매우 단순한 운용이었습니다.

 

그러다 이번 팀 프로젝트를 진행하면서 좀 더 자세히 다루게 되었는데요.

 

 

저희팀은 GitFlow 전략을 일부 채택해서 main과 develop 브런치를 기본으로 두고

깃허브에서 이슈를 생성, 이슈번호를 토대로 브런치를 만들어 작업 내용을 Commit하기로 했습니다.

 

기능을 완성한 후에는 pull request를 생성해 develop과 Merge하고

문제가 없으면 다시 pull request를 생성해 main과 Merge하는 방식입니다.

우리 팀의 깃 전략!

 

그런데 여기서 또 문제가 생깁니다. (매일이 문제 해결의 연속...🥹)

 

저는 깃허브에서 단순히 Repositories만 생성해봤지

이슈가 뭔지, 풀 리퀘스트가 뭔지, 전혀 몰랐던 겁니다.

그치만 어쩌겠어... 팀 프로젝트에 필요하면 어떻게든 해봐야지!

 

 

그래서 이번 포스팅에선 실제 작업을 예시로

어떻게 이슈를 작성하고 브런치를 만들고 풀 리퀘스트를 쓰는지 알아보겠습니다!

 

 

 

 

 

🎷 이슈와 브런치 만들기

팀 프로젝트 초기에는 사용자 화면 디자인과 DB설계가 완벽히 끝난 상태가 아니어서

우선 할 수 있는게 뭘까 생각하다가 관리자 페이지를 만들어보기로 했습니다.

 

간단하게 사이드바와 컨텐츠 영역을 분리하고

요구사항 정의서에 합의된 관리자 메뉴들을 카테고리로 집어 넣었습니다.

 

 

1️⃣ Projects 생성

팀원들에게 제가 관리자 페이지 작업을 시작하겠다고 알리긴 했지만

더 세부적으로 어떤 작업이 있고 그중 무엇을 진행중인지 알리기 위해 프로젝트를 만들기로 했습니다.

 

저희 팀 조직명은 BeautyRoutine!

 

깃허브에선 본인 아이디 외에 별도의 조직을 생성할 수 있습니다.

저희 팀은 BeautyRoutine이라는 조직을 만들어 공동 작업을 하기로 했는데요.

 

조직 메인 화면으로 들어와 상단의 탭을 보면 Projects 가 있습니다.

누른 후 프로젝트 목록에서 New Project 버튼을 찾아 눌러봅시다.

 

Project의 탬플릿을 정하는 화면

 

생성 화면으로 들어오면 여러가지 탬플릿을 보여주는데

일단은 가장 기본적인 Board를 선택 후 프로젝트 이름을 입력하고 Create 해줍니다.

 

포스트 작성 전에 테스트 겸 만든 프로젝트

 

저는 norangmoran's admin project라는 이름으로 프로젝트를 생성했습니다.

 

그 후 무슨 작업을 할 건지 Todo란의 Add item을 눌러 추가해줍니다.

내용 입력 후 Create a draft 또는 Ctrl + Enter를 눌러줍니다.

 

 

저는 할 일의 큰 기준을 메인화면 구성, 대분류 카테고리 명으로 잡았고

메인화면 구성은 테스트 겸 이미 완료했으니까 주문 관리 카테고리를 해보겠습니다.

 

Todo에 추가한 작업 중 시작할 작업을 In Progress로 드래그해 옮겨준 다음 클릭합니다.

 

할 일(영역)에 대한 세부 내용을 채우고 새로운 기능 추가를 이슈로 만들자!

 

클릭하면 좀 더 세부적인 분류를 추가할 수 있습니다.

 

Projects는 이미 프로젝트를 통해 만들었으므로 자동으로 추가되 있습니다.

Assignees는 담당자를 설정할 수 있는데, 클릭 후 제 아이디인 norangmoran을 설정했습니다.

Labels은 말 그대로 라벨입니다. 해당 영역의 시작점 이슈라는 뜻에서 good first issue를 선택했는데

팀원끼리 정해둔 규칙이 있다면 그것을 따르는 것이 좋습니다.

Type은 유형 분류인데 저는 작업영역을 만들었다는 뜻에서 Task를 선택했습니다.

 

2️⃣ 이슈 추가하기

분류를 수정했다면 이제 해당 작업 영역에 어떤 기능을 추가할 것인지

새로운 이슈를 추가해보도록 합시다.

 

 

먼저 방금 화면의 상단 오른쪽을 보시면 ... 표시가 있습니다.

이것을 눌러 Open in new tab을 눌러줍니다.

 

그러면 방금 만든 Task를 곧장 Issues 탭에서 열어볼 수 있고

여기서 다시 상단 오른쪽을 가셔서 New issue 버튼을 눌러 새로운 이슈를 추가합니다.

 

종류는 새로운 기능의 추가이므로 기능 제안(Feature Request)를 선택합니다.

 

팀장님이 이슈 탬플릿을 설정해주셔서 편하게 작성 가능하다!

 

팀의 탬플릿대로 내용을 작성해주고

담당자를 배정하고

새로운 기능의 추가이므로 라벨을 enhancement로 설정하고

타입도 기능 추가를 뜻하는 Feature로 설정하고

프로젝트를 선택해준 다음

 

Create 버튼을 눌러 이슈를 생성해줍니다.

 

3️⃣ 브런치 생성

브런치 생성 버튼

브랜치 이름 작성란

 

생성된 이슈의 상세내용으로 들어가서 오른쪽 목록을 보면 Development가 있습니다.

 

여기서 브런치를 생성할 수 있는데, 저희팀은 신규작업을 무조건 feature/에서 하기로 했고

develop 브런치에서 체크아웃하기로 했으므로 팀 규칙을 고려해 이름을 작성해줍니다.

 

 

여기서 브런치를 만들 수 있는 방법이 2가지가 있는데

하나는 Create brance 버튼을 누른 후 뜨는 깃 명령어를 복사한 후

프로젝트 폴더 내부로 가서 마우스 오른 클릭 => Open git bash here => 명령어 붙어넣고 실행

 

또는 깃 명령어를 무시한 후 본인이 쓰는 깃 관리 애플리케이션에서

develop에 체크아웃 => fetch => pull => 동일한 이름으로 브런치 생성 합니다.

저는 Soucetree를 쓰고 있어서 여기서 브런치를 만들었습니다.

 

 

이슈를 통해 브런치를 만들면 해당 이슈에서 커밋 내역을 자동으로 추척해준다!

 

이제 그렇게 만들어진 브런치를 통해 작업한 내용을 커밋하면

이슈에서 해당 브런치로 한 커밋을 전부 추적해 볼 수 있습니다.😀👍

 

 

 

 

 

🎺 풀 리퀘스트와 머지

작업이 전부 끝났다면 이것을 develop에 반영하기 위해 pull request를 작성합니다.

 

 

다른 팀원이 App.js에 사용자 화면의 라우터를 구성하면서

관리자 화면에도 사용자 화면에 있어야 할 헤더가 같이 뜨는 이슈가 있었는데요.

 

이건 빨리 반영되어야 관리자와 사용자 화면을 각각 나눠서 작업하기 편할 것 같아 PR을 올려봤습니다.

 

 

1️⃣ Pull request 작성하기

pull request는 내 작업량을 공용으로 사용하는 브런치(main 또는 develop)에 반영하고 싶으니

코드에 이상은 없는지 확인해주고 수정할 곳을 알려주거나 승인을 해달라는 요청을 올리는 작업입니다.

 

이슈를 만들었던 레포지토리의 상단 탭을 보면 Pull requests가 있습니다.

 

여기서 New pull request를 눌러 요청을 추가할 수 있고

이슈를 통해 생성한 브런치를 통해 커밋한 내용이 있다면 Compare & pull request를 통해 추가할 수도 있습니다.

 

 

PR 내용 작성중~

 

팀 규칙에 맞춰 내용을 작성하고

Reviewers에 리뷰해줬으면 하는 사람을 추가한 다음

Assignees에 이 작업을 담당한 사람을 선택해줍니다.

 

빠르게 응답해주는 팀원들🥰

 

그러면 이런 식으로 팀원들이 코드를 확인했다는 표시를 달아줍니다.

 

2️⃣ 코드 리뷰 하기

오는 것이 있으면 주는 것도 있어야 하는 법!

 

팀원들이 코드 리뷰를 해줬으니까 우리도 어떻게 하는지 방법을 알아봅시다.

 

어짜피 코드 공개로 해놨는데 안 가려도 됐으려나...?

 

리뷰하려는 pull request로 들어가면 상단 탭에 Files changed가 있습니다.

여기서 수정된 내용을 한 페이지에 모아서 볼 수 있습니다.

 

수정된 내용을 확인하셨다면 바꿨으면 하는 내용을 적어 comment를 submit 할 수 있고

작업한 팀원에게 수고했다는 말과 함께 Approve를 submit 해서 승인할 수도 있습니다.

 

 

 

 

 

🔥 결론

혼자 마구잡이로 개발하던 것에 비하면 다소 번거로운 과정이 추가되었지만

issue를 생성해 개발을 시작하니 쉽게 원하는 작업의 버전을 찾을 수 있게 되었습니다.

 

 

물론 커밋 메시지를 확인할 수도 있지만 issue에 비해 많은 내용을 적을 수 없어 찾기 어렵습니다.

뿐만아니라 탬플릿을 따로 설정해둘 수 없으니 작성 내용도 제각각이라 검색도 어려웠죠...

 

분명 그 달에 했던 커밋인데 아무리 찾아도 원하는 버전을 찾을 수 없었던 그때의 막막함이 이랬달까...

 

기왕 배운거 앞으로도 쭉~ 유용하게 써먹어야 겠습니다! 🤭

 

 

 

아마 다음 포스팅에는 오라클과 MySQL의 차이를 쓰게 될 것 같아요.

 

DB 테이블 만들면서 어려움이 많았기 때문에 할 말이 또 많을 것 같습니다...

오라클 너무 까탈스러워...🥲