Git flow, gitignore, convention 정해서 협업하기

Git flow "프로젝트 규모에 따른 브랜치 체계"

협업할 때, 브랜치 나누는 방식이 굉장히 다양하다는 것을 알게되었다.

1. 특정 기능을 구현하는 feature 브랜치
2. 기능 구현 완료했으면 develop 브랜치로 pr 날림
3. develop 에서는 테스트를 위해서 release pr 날림
4. 테스트 완료되면 release에서 develop 과 main 브랜치에 각각 pr 날림
5. main 에서는 merge
6. 그럼 hotfix는? 긴급 버그 수정!!
   (긴급인만큼 develop 과 바로 main 으로 각각 pr 날림)

이 절차들이 첫번째 그림에 대한 프로세스이다,,

브랜치 이름을 마음대로 하는 것이 아니라, 맡은 기능의 이름으로 명시해주어야하고
브랜치는 main 과 그 이하 feature 까지밖에 생각 안해봤는데, 프로젝트 규모가 크다면 저렇게 많은 단계를 나누어서 체계적으로 소스를 관리하는구나 싶었다. 절대로!! main으로 바로 푸시할 일은 없는,, 저렇게 큰 규모의 프젝을 언젠가 해보고 싶다;ㅎㅎㅎ

 

그러나,, 강사님 말씀대로 지금은 main~feature 까지 사용하다가, 배포하는 방법 배우면 deploy~main~feature 정도까지 사용하고, 테스트하는 방법까지 배우고 나면 test 브랜치까지 추가해서 총 4개의 브랜치 사용하는 것을 추천한다고 하셨고 공감했다!!

통상적인 Commit Message

• Feat : 새로운 기능 추가
• Fix : 버그 수정
• Env : 개발 환경 관련 설정
• Style : 코드 스타일 수정 (세미 콜론, 인덴트 등의 스타일적인 부분만)
• Refactor : 코드 리팩토링 (더 효율적인 코드로 변경 등)
• Design : CSS 등 디자인 추가/수정
• Comment : 주석 추가/수정
• Docs : 내부 문서 추가/수정
• Test : 테스트 추가/수정
• Chore : 빌드 관련 코드 수정
• Rename : 파일 및 폴더명 수정
• Remove : 파일 삭제

협업할 때, 컨벤션의 중요성

• File directory
• Commit Message
• Issue
• PR 멘트 (closed #이슈번호 적어주면 이슈 자동 닫힘)

가독성을 위해, 통일성을 위해 컨벤션을 만들어서 그 규칙을 따르는 것은 매우 중요하다!!!

꿀팁) Issue나 PR멘트의 템플릿을 만들어서 푸시하면 깃허브에서 자동으로 통일된 양식을 사용할 수 있다. 아래와 같이!

pull_request_template.md

## 작업 개요 (이슈 번호)


## 작업 내용 (변경 사항)


## 스크린샷


## 테스트 결과


## 리뷰 요청 사항

issue_template.md

## 목적


## 세부 내용

Branch protection

이 부분 또한 새롭게 알게되었다. 깃과 깃허브에 그동안 사용하지 않았던 기능들이 정말 많은 것 같다...

Settings --> Branch 들어가서 기본적으로 이 정도는 체크를 해주는 것이 좋다.

의미) "무조건 pull request 를 통해서만 merge 가 가능하고, 그냥 push 는 거부해. 그리고 pull request 에 대해서 최소 1번의 approval 코드 리뷰가 있어야만 merge 가 가능해"

※절대 체크하면 안 되는 부분※

강제 푸시 및 삭제는 절대 금물

.gitignore 은 필수이다

.gitignore 파일에 버전관리를 하지 않을 파일들을 적어주고 저장함
그런데 버전관리에서 제외시킬 파일이 이미 커밋이 된 상태라면!

git rm -r --cached .
git add .
git commit -m "Update .gitignore"

캐시삭제하고! 다시 git add commit 하면 됨