[Github] Github로 협업하는 방법 - repo 생성 시 할 일 (feat. 두번째 프로젝트 회고)

 

 

애플 디벨로퍼 아카데미에서 진행한 두번째 프로젝트가 끝이났다. 두번째 프로젝트는, 정말 느낀게 많은 프로젝트였다. 어쩌다가 내가 약간의 리드..?를 하게 되었는데 그 과정에서 내가 못했던 것을 기준으로 앞으로는 어떻게 해야할지 정리해보기로 했다. 약간,,, 나중에 혹시 또 내가 github 관리를 맡게 되었을때, 뺴먹지 않고 모든것을 했나? 하는 체크리스트!로 활용될 포스팅이다.

 

🚀 Github Repo 생성하기

진짜 어쩌다가 앱개발 2개월차인 내가 리드를 맡게 되어서, Team repo 관리도 어쩌다가! 내가 하게 되었다. Git을 이렇게 제대로 처음 다뤄보는 것은 처음이라 겁나기도 했다. 아니나 다를까 역시나 첫 단계부터 내가 실수를 저질렀다.

이번에 내가 실수했던 부분은 바로 repo 생성 단계에서 .gitignore 을 생성할 때다. ▶ 무슨 일이 있었는지 보러가기

 

.gitignore에 어떤 키워드를 넣어야 할지 몰라서 기본으로 제공하는 Swift 키워드만 넣어서 gitignore 을 생성했었다. 그리고 아 나중에 바꿔야지~ 하고 넘어갔기도했다 후 ,, 후회된다. gitignore 파일을 제대로 생성하지 않으면, 로컬에서 올라가지 않아도 될 파일들이 전부 올라가게 되어 conflict가 생기기 때문에 중요하다.

 

✏️ gitignore 만들기

https://www.toptal.com/developers/gitignore

gitignore.io

gitignore은 위 홈페이지에서 간단하게 생성 가능하다. 원하는 키워드를 넣어서 create를 눌러주면 자동으로 소스코드를 만들어준다. 해당 소스코드를 전부 복사해서 .gitignore파일을 생성해주면 도니다. 생성할때 필요한 키워드를 잘 익혀두자. 

< iOS project gitignore 추천 키워드 >

• swift
• xcode
• cocoapods
• Objective-C (안넣어도 되지만, 추천한다고한다!)
• MacOS 도 추가해주자 (쓸데 없이 생기는 DS_Store 이놈자식이 여기서 생기는것이다!)

 

✏️ Issue Template 만들기

issue가 왜 중요한지 몰랐고, 첫번째 프로젝트에서도 issue 기능을 사용하지 않았다. 하지만,, 이번에 절실하게 그 필요성을 느꼈다. 깃허브는 이슈번호가 #29 처럼 숫자로 형성이되는데, commit message 나 code review, comment 어디에든 #번호 만 쓰면 해당 이슈와 연결된다. 협업할 때 내가 어떤 개발을 진행하고 있는지, 어떤게 문제가 되는지 등 나의 상황을 팀원들에게 공유하기 가장 간단한 방법인것 같았다.

issue를 제대로 사용해보고 싶어서 issue 템플릿을 만들었다. 

하지만 이번 프로젝트에서, Issue를 잘 활용하고 싶었지만, 욕심만큼 잘 되지 않았다. 아무래도 이슈 생성에 대한 규칙을 정하고 넘어가지 않아서 인 것 같았다. 

👉 Issue 규칙 정하기

이슈 규칙은 어떻게 정해야할까, 일단 우리 팀 이슈를 보면 정리되어있지 않은 제목 스타일, 그리고 무자비한 라벨사용이 문제였다. 지금은 내가 제목을 일관되게 다 정리해두었지만,,,일관되지 않은 느낌이랄까? 

1. 제목 -제목은 아래 키워드로 통일하면 좋을 것 같다.

• [Add] UI button 구현
• [Feat] UI button 저장 기능 추가
• [Bug] 버튼 누르면 색깔 안바뀌는 버그
• [Refactor] 코드 리팩토링
• [Chore] setting과 관련한 문제 

우리 팀의 이슈 목록이다. 제목은 이런식으로 통일해놨다. (잘한 팀의 이슈 탬플릿을 베꼈당 ㅎㅎ) 하지만 어떤건 [Bug] 이고, 어떤건 [Fix]이다. 이런 키워드를 통일하는 규칙을 정했으면 더 깔끔한 제목통일이 됐을 것 같다. 그리고,,, 이번에 있는 40개정도의 이슈의 제목을 모두 내가 수정해서 바꿨는데 이런 일도 생기지 않겠지.

2. 라벨 - 라벨도 이렇게 만들어보자

• View 이름
• 팀원 이름
• UI Design 
• Bug
• 필요시 chore 이나 docs, setting 등

우리 팀의 라벨은 도대체 view를 기준으로 나눈건지, 키워드로 나눈건지 이해가 되질 않는다. (실제로 멘토분께 어떤 기준으로 나눈거냐고 질문이 들어오기도 했다.) ListView는 없는 뷰인데, 도대체 뭐며,, pin은 넣은것도 있고 안넣은것도있고. 체계가 잘 잡혀있지 않았다. 다음부터는 또 위에처럼 규칙과 라벨을 모두 정하고 시작해야지,, 

 

✏️ Branch 규칙 정하기

develop
feat/54-mainview-ui

처음에 브랜치 어떻게 파야할지 몰라서 아래처럼 팠었는데, 독특한 브랜치 이름이라고 그랬다 크크크 🤓 그래서 다들 보통 사용한다는 방식인 위 방식처럼 바꿔보자... 그리고 브랜치는 바로바로 삭제하자 지금 남아있는 브랜치만 몇개야 도대체..

 

✏️ PR Template 만들기 

이렇게 미리미리 PR 탬플릿을 만들자! 템플릿은 setting 탭에서 만들어도 되고, .github 폴더 내 에서 만들어도 된다. (프로젝트 생성하면 가장 상단에 뜨는 그 .github 폴더)

나는 처음에 이슈탬플릿만 만들어서 아래처럼 PR 내용이 통일되지 않고 제각각인 사태(?)가 발생했었다. 이런걸 막고 동일한 형태의 pr을 작성하고 리뷰받자!!

예시 1

예시2

 

✏️ PR 규칙 만들기

우리팀의 문제 중 하나는, 바로 코드리뷰를 하지 않는다는 점이었다. 그래서 팀원들끼리의 업무공유가 더디고,,, 코드 통일이 안된다는 거..?

외로운 Reviewer

그리고 또하나의 가장큰 문제는, pr 을 올리고, 리뷰가 이루어지지 않아 merge되는 속도가 느렸다. 그래서,, 한번에 pr 10개정도가 open 되어잇었고 결국.....엄청난 conflict가 생겨서 xcode가 아예 열리지 않는 사태까지 발생했다. 울고싶었다 흐흑흑. 그래서 혹시 다음 팀플때 또 내가 ,, github 관리를 담당한다면 꼭 하고 싶은게 pr 규칙 정하는것이다. 아래처럼 정하면 될 것 같다.

1. PR 올리면 팀원들에게 공유 
2. 하루 매일매일 올라온 PR에 대해서 코드리뷰 남기기
3. PR은 open 되고 36시간 이내로 팀원 2명 이상의 approve를 받아야하고
4. 2명 이상의 approve 가 있을 경우 머지 가능!

+ 코드리뷰 규칙

또 코드리뷰에 대해서 생각해보았다. 코드리뷰를 어떻게 하면 잘 할 수 있을까 생각하다가 뱅크샐러드의 pr 리뷰 규칙을 발견했다.

https://blog.banksalad.com/tech/banksalad-code-review-culture/

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

코드리뷰를 하다보면, 되게 사소한 것을 고쳐달라고 말할때도 있고, 무조건 고쳐야할때가 있다. 이것을 1~5 숫자를 이용해서 리뷰한다는 점이 좋았다! 다음 리뷰에서는, 무조건 이 규칙을 따라보도록 하자.

• P1 ) 꼭 반영해주세요.
• P2 ) 적극적으로 고려해주세요.
• P3 ) 웬만하면 반영해주세요 (comment)
• P4 ) 반영해도 좋고, 아니어도 좋아요. (approve)
• P5 ) 그냥 사소한 의견입니다. (approve)

그리고 코드리뷰를 받았을 때, 수정하고 작은 단위로 커밋을 남기고 커밋 번호를 답변으로 남겨주자.

 

🚀 코드 컨벤션 정하기

코드 컨벤션을 정하지 않았더니 리뷰에서 '여기서는 엔터해달라', '엔터를지워달라' '띄어쓰기를 지워달라'.. 라는 리뷰를 엄청나게 하는 나를 발견할 수 있었다. 왜일까? 고민해보니,,,, 코드를 작성하기전에 코드컨벤션을 안정했더라,,,, 휴,,, 그래도 lint 가 있어서 대충 규칙이 정해질줄 알았는데 사소한 것들이 정해지지 않아서 이를 수정하는데도 시간을 쏟았던것 같다.

린트를 지키자아아아

다음 프로젝트에서는 코드 컨벤션을 꼭 정하고 시작해야겠다. 린트가 있어도, 여기서 잡아주지 못하는 사소한 것들이 되게 많았다. 아니 그냥 오지게 많다! 다음 프로젝트때는, 아래 글을 참고해서 코드 컨벤션을 정하고 시작해야겠다. 아래에는 내가 또 이번 팀에서 어디서부터 문제가 되었을까 찾아보다가 찾은 '스타일쉐어의 코드 컨벤션'이다. 이것을 참고해서 적용시켜봐야겟다!

https://github.com/StyleShare/swift-style-guide

GitHub - StyleShare/swift-style-guide: StyleShare에서 작성한 Swift 한국어 스타일 가이드

 

🚀 Commit Message 규칙 정하기

커밋 메세지 규칙을 정하긴 했는데, 아무데서 따와서 정하다보니까 어떤 UI화면 구성은 add로 되어있는데, 어떤건 feat으로 되어있고 이런식으로 제대로 체계가 잡혀있지 않았다. 그래서 우리에게 꼭 필요한 commit message만 제대로 정의하고 체계를 정하고 넘어가는 것이 중요하다고 생각되었다.

그리고 커밋메세지에 이슈번호를 남기면, 해당 이슈에 커밋내역이 자동으로 남겨지게 된다. 이 기능도 적극적으로 활용했어야 했는데 그렇지 못해서 아쉬웠다. 

이렇게 이슈번호를 남기면 해당 이슈 밑에 뜬다!

commit message 규칙은 이렇게 정해보고 시작하자.