git으로 함께 일하기 | merge 전략, PR, 커밋 컨벤션

내가 속한 팀은 신생 팀이고 팀 단위의 git 전략은 딱히 존재하지 않았다. release log를 남기기 위해 커밋 컨벤션을 만들어놓은 정도였다. 사내 다른 개발자들의 브랜치 머지 전략, 커밋 로그 컨벤션 등을 보고 팀원들에게 제안해 적용해보았다.

 

브랜치 머지 전략

🧚‍♀️참고: https://moonsupport.oopy.io/f8a56d78-1425-4987-9a34-30ed30885d2c

 

좌) 변경 전 우) 변경 후 현재 

군데군데 merge commit이 섞여 있어서 히스토리를 매끄럽게 알기 어렵다. 그래서 PR을 머지할 때 push 브랜치와 base 브랜치에 따라 머지 전략을 다르게 하기로 했다. 현재는 merge commit이 사라지고 의미있는 커밋들만 남아서 히스토리가 깔끔해졌다.

 

1. develop(or stage) → master : create a merge commit 옵션 사용

: 위에 처럼 merge commit이 남는다. master 브랜치에는 merge 시점이 필요하니 해당 전략을 사용한다. 기존에는 이 전략을 모든 브랜치에 사용해서 커밋 히스토리 곳곳에 머지 커밋이 자주 나타났다.

 

2. feat or fix → develop: squash and merge 옵션 사용

: PR의 커밋 로그를 하나로 묶을 수 있다. 원자적인 커밋 또는 PR 기능과 전혀 상관 없는 커밋 로그(ex. 콘솔 로그 제거)를 하나로 합쳐서 의미 있는 커밋 로그만 남긴다. PR 제목이 커밋 로그가 된다.

 

3. develop → feat or fix: rebase and merge 옵션 사용

: merge commit이 남지 않는다. develop 브랜치를 내 브랜치로 pull할 때 사용해 쓸데 없는 merge commit을 남기지 않는다.

 

---

 

깃모지

- gitmoji-cli repository

- 깃모지 활용 방법

 

커밋 로그 맨 처음에 이모지를 사용해 커밋 로그를 직관적으로 바꾼다. 처음에 깃모지가 나왔을 때는 너무 산만해보여서 좋은 커밋 메시지 작성법을 참고해 [Fix], [Feat], [Chore] 등 prefix를 앞에 붙여 사용했다.

 

깔끔하고 직관적이다. 다만 일일이 적어줘야 하고, fix, Fix 등 대소문자가 틀리거나 오타가 나는 등 typo 문제가 있다. 

 

반면, gitmoji의 경우 설치해서 'gitmoji -c' 명령어를 사용하면 프롬프트에서 커밋 성격에 맞는 이모지를 고를 수 있다. 

 

 

 

 

또한, 이모지로 commit 검색이 가능하다.

git log --oneline --grep :robot

 

 

커밋에 맞는 깃모지 찾기 (아니면 gitmoji -c)

$ gitmoji list -s <검색어> 

# or 

$ gitmoji list --search=<검색어> 

# or 

$ gitmoji list <검색어>

 

 

 

 

---

 

PR 템플릿 추가

 

.github/PULL_REQUEST_TEMPLATE.md 생성한다.

 

default 브랜치에 pr 날릴 때 템플릿이 적용된다.

 

## 개요 :mag:

`어떤 이유에서 이 PR을 시작하게 됐는지에 대한 히스토리를 남겨주세요.`

## 작업사항 :memo:

`해당 이슈사항을 해결하기 위해 어떤 작업을 했는지 남겨주세요.`

## 테스트 방법

`리뷰하는 사람이 어떻게 테스트할 수 있을지 간략히 써주세요.`

 

PR을 날리면 아래처럼 템플릿이 적용된다.

 

 

 

---

 

Master 브랜치 Push 제한: Protect Master Branch!

github project - settings - branches - add rule에서 Restrict who can push to matching branches 옵션 추가

 

위의 설정은 master 브랜치에 실수로 푸시하는 일이 없도록 푸시할 수 있는 팀원들을 제한한다. 팀에 들어오지 얼마 안된 뉴비분들이 실수로 마스터 브랜치에 푸시하는 일을 예방할 수 있다.

 

옵션에 사람을 추가하면 해당 사람만 그 브랜치에 푸시할 수 있다. 단, 해당 브랜치에 PR을 올리는 것은 가능하다. 마스터 브랜치에 안정적으로 코드를 반영할 수 있는 방법 같다.

 

include administrators 옵션을 선택하면 Admin 유저도 master branch 푸시 제한 옵션의 대상이 된다. (어드민 유저도 화이트리스트에 들어가지 않는 한 push가 제한된다.)

 

참고로 이 기능은 organization에 속한 repository에서만 사용 가능하다.