Git : git flow, commit convention, issue, PR

● git 관리 전략 (flow)

기본적인 전략은 trunk based flow(기본 브랜치를 trunk 라고 함)로 필요할 때만 분기를 발생시키는 것이다.

때문에 마구잡이로 푸쉬할 가능성을 배제하기 위해서 미리 브랜치를 정하는 전략을 쓴다. 아래는 대표적인 3가지 flow다.

 

1. git flow

깃플로우는 main과 develop 브랜치를 주축으로 하여 hotfix, release, feature 브랜치로 각 분기를 나누는 형태를 말한다.

main 에서 develop, release 브랜치 후 develop에서 각 기능별로 feature를 브랜치한다. feature 들은 develop에서 merge 되고, develop은 release에 merge해 테스트를 거치고 main에 머지된다.

hotfix는 급히 수정해야하는 사항들이기에 main에서 브랜치후 바로 main으로 머지된다.

 

main과 develop은 주축인 만큼 하나의 브랜치만 두고 나머지 브랜치들은 기능별, 항목별로 따로 분류한다.

 

일반적으로 깃플로우는 큰 규모의 프로젝트나 퀄리티 보장이 중요한 프로젝트에서 활용되는 전략이다.

 

2. github flow

깃허브 팀에서 썼던 전략으로 소규모, 팀규모에서 주로 사용되는 전략이다.

가장 단순하고 효율적인 전략인데, branch를 main, feature들 로만 두어 작업되는 feature들이 main에 바로 적용되게끔하는 전략이다. 

 

실습에서는 이 형태를 사용했다. 왜냐하면 코드가 없어 서비스 배포나 테스트를 할 필요가 없었기 때문이다.

 

3. gitlab flow

깃 플로우 보다는 효율을 중시하고 깃헙플로우보다는 안정성을 추구한 전략이다.

아래와 같이 4개의 브랜치를 만들어서 메인브랜치가 깃플로우의 디벨롭브랜치 역할을 하게 된다.

production

pre-production

main

feature

 

main에서 브랜치한 feature가 완료되면 메인으로 머지되고, 작성된 메인은 pre-production 즉 테스트를 위한 브랜치로 나뉜다. 테스트가 완료되어 배포승인이 떨어지면 production으로 브랜치되어 배포된다.

 

스타트업 규모에 적합한 전략이다. (참고로 실무에서는 이름을 더 명확히 쓴다고 한다.)  

 

● commit convention

커밋 메세지 규칙인데 예로 보면 아래와 같다.

Feat: Add function to login(제목에 해당한다.)

로그인 요청을 위한 함수구현 (본문에 해당)

Close: #1(앞서 배운 이슈번호를 통해 자동으로 이슈를 닫는 역할을 한다.)(꼬리말에 해당)

 

위의 예시처럼 commit을 작성하려면 이전처럼 커밋 제목만 작성하는 

git commit -m " " 의 형태가 아니라 git commit " " 명령으로 터미널 상에서 I > 본문/꼬리말을 작성한 뒤 :wq 로 커밋종료한다.

 

이렇게 작성된 커밋을 깃허브에 푸쉬할 경우 해당 내용이 모두, pull request에 올라간다. 

때문에 무엇을 위해 이 작업을 했는지, 어떤 함수/변수를 추가했는지 등을 자세히 적어주어야한다.

(참고로 이렇게 작성하여도 로그에는 제목만 기재된다.)

 

*제목 타입 : Feat, Fix, Env, Style, Refactor, ..  등이 있다.

*꿀팁 : 깃헙에서 커밋 로그를 확인 할땐 시계표시를 눌러서 확인할 수 있다.

 

● issue, pull request template(틀)

이슈나 풀리퀘스트 내용의 기본형태를 미리 만들어두는 파일이다.

git으로 관리되는 폴더 내에 .github 폴더를 만들어서 md파일로 미리 작성한다.(레포에 푸쉬하기전에)(앞의 .은 숨김처리 한다는 뜻이다.)

 

예시로 하나를 들자면 

 

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

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

## 스크린샷

## 테스트 결과

## 리뷰 요청 사항

 

이러한 형태로 템플릿을 작성한다.

 

*꿀팁으로 깃헙 파일을 pull하는 과정에서 hint가 뜨는 에러의 경우 commit 이력이 어긋나서 지정하라는 컴플릭트이다.

이런 경우엔 git pull origin main --no-ff 로 해결하면된다.

 

● 이슈마다 템플릿 만들기 기능

깃허브에서 기존에 작성되어있는 템플릿을 이슈 타입에 따라 만들 수 있다.

settings > issues > set up template > add template 순으로 만들면 된다.

이슈 생성시에 각 템플릿을 선택하면 된다.

 

● branch pretection

main에 바로 push를 하거나 코드리뷰없이 merge하는 경우를 방지하기 위해 설정한다.

즉, 해당 권한을 차단하는 기능이다.

깃허브에서 settings > branches > add branch > rule 로들어가 설정할 수 있다.

 

예를 들면 첫번째 항목은 특정 브랜치로 푸쉬하는 것을 제한하는 옵션이다.

이때에 비슷한 이름의 브랜치가 많다면 feature*로 모두 feature가 들어간 모든 브랜치에 푸쉬가 불가능하도록 설정하는 방법이 있다.

 

● git ignore 

DB접큰 키나 AWS 인스턴스 키파일 등이 git push에서 깃허브에 공유되지 않도록 설정하는 기능이다.

에디터에서 .gitignore 파일을 생성하여 해당 파일안에 깃 관리를 받지않을 중요파일명을 기재하면된다.

단, 이 과정 전에 이미 키파일을 add, commit 했다면 이 기능을 해도 의미가 없다.

때문에 그런 경우에는 git rm -r --cashed 명령을 사용하여 캐시를 지울 필요가 있다.

 

이것으로 할당된 git강의가 종료되었다. 과정이 즐거워서 아쉬웠지만, 실습에서 적용해볼 수 있는 장면들이 많아 많이 배웠다.

후에 다른 협업 실습, 사이드 프로젝트 등에서 유용히 이용해야겠다.

 

위 내용은 2022.12.15에 공부한 내용입니다.

링크 : https://dudwls3278.tistory.com/13