[내배캠][TIL] 59일 차 - 수요일, 심화 프로젝트와 GitHub 협업

 

 

⏱️ 오늘의 일정 ⏱️

9:00 ~ 10:00 - 심화 프로젝트 발제
10:00 ~ 13:00 - 심화 프로젝트 - 기획, erd, api
13:00 ~ 14:00 - 점심시간
14:00 ~ 15:30 - 쿼리 최적화 특강
15:30 ~ 18:00 - 심화 프로젝트 - 다 같이 세팅! code with me
18:00 ~ 19:00 - 저녁 시간
19:00 ~ 21:00 - 심화 프로젝트 - 기능 개발
21:00 ~ 22:00 - 최종 프로젝트 회의

 

 

 

잡담

저번 팀 프로젝트가 끝나고 거의 TIL을 작성하지 않았는데 정말 오랜만에 블로그에 먼지를 털었다.

50일 차에서 59일 차가 된 걸 보니 조금 양심이 찔렸다.

개인 공부 기간 동안 조금 쉬엄쉬엄 했었는데 어느새 꿀 같던 시간이 끝나고 다시 팀프 기간이 시작되어 버렸다.

 

이번엔 최종 팀프로젝트에서 챌린지 팀에 선정되었기 때문에,

저번 프로젝트를 진행할 때처럼 밤늦게까지 이 프로젝트에만 매진할 수는 없다.

오늘도 9시부터는 최종 팀의 회의가 진행된다...

 

그건 그렇고 갑자기 프론트를 만들라니 이게 무슨 소리지?

4일이라는 짧은 시간에 어떻게 프론트를 구현하라는 건지 매우 화가 난다.

사전 지식이 있었으면 모르겠는데 정말 바닐라 js 조금이 끝인 생 초짜들한테!

 

 

GitHub 템플릿 - Issue 템플릿, Pull Request 템플릿

이전 팀에서는 템플릿을 사용하지 않았었는데 이번엔 좀 더 Issue, PR 기능을 잘 활용하기 위해 템플릿을 쓰기로 하였다.

 

이슈 템플릿

 

이슈 템플릿은 레포지토리의 Setting -> General -> Features에서 만들 수 있다.

 

 

Add template를 클릭하면 원하는 유형의 템플릿을 설정하게 한다.

Bug report, Feature request는 어느 정도 기본적인 템플릿을 제공해 준다.

 

위는 기본적으로 제공하는 Feature 템플릿이다.

 

템플릿을 저장하기 위해서는 Propose changes 버튼을 클릭한다.

그럼 Commit을 진행하게 된다.

 

잠깐 그냥 깃허브 설정 바꾸는 거 아니었나? commit은 왜 필요하지?

 

커밋을 진행하게 되면 .github라는 폴더가 생긴다.

그리고 ISSIE_TEMPLATE라는 폴더 안에 우리가 만든 템플릿 마크다운 파일들이 들어가게 되는 것.

 

그런데 여기 아래에 PULL_REQUEST_TEMPLATE이라는 마크다운 파일도 신경 쓰이지 않나요??

 

Pull Request 템플릿

PR 템플릿은 .github 아래에 PULL_REQUEST_TEMPLATE.md라는 이름으로 파일을 생성하면 된다.

기본 제공하는 형식은 없기 때문에 직접 만들어야 한다.

https://amaran-th.github.io/Github/[Github]%20Issue%20&%20PR%20Template%20%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0/

[Github] Issue & PR Template 설정하기

나는 이 사람의 템플릿을 사용하였다.

여유가 된다면 팀에 맞는 템플릿을 직접 설계하는 것도 좋을 것 같다.

 

 

PR이 Approve 되어야 Merge 가능하도록 하기

 

Repository의 Settings -> Branches로 가보자.

 

이건 내가 헤맸던 부분인데, 구글링을 했을 때 대부분 이전 branch rule 화면이 나오고 있었다.

Add classic branch protection rule을 클릭하면 이전 방식으로 branch rule을 만들 수 있다.

 

Branch name pattern에는 적용할 브랜치를 적어준다.

default 브랜치인 dev로 적었는데 이렇게 브랜치 이름을 적을 수도 있지만

** 와일드 카드를 사용하여 전체 브랜치에 적용할 수도 있다.

 

Require a pull request befor merging을 체크하여 머지 전에 승인을 필요로 하도록 한다.

아래 드롭다운에서 approve 수를 선택할 수 있다.

자신이 올린 pr에는 approve 할 수 없기 때문에 다른 사람이 코드를 확인하지 않았는데 merge를 진행하는 불상사를 막을 수 있다.