7월 2째주 - github강의(관리전략)

23/07/13

 

오늘은 깃 관리전략에 대해 배웠다.

세부 수업 목표는 다음과 같다.

1. Git Flow, Github Flow 등을 공부하며 현업의 Git 관리 전략을 이해한다.
2. .gitignore 를 활용한 파일/폴더 관리 제외 방식을 이해한다.
3. 협업을 위한 Github 활용 과정을 직접 진행한다.

먼저, 깃 관리 전략에 대해 설명해보자.

[Git 관리 전략]

- git flow, github flow, gitlab flow의 개념

기본적으로 하나의 중심 브랜치로만 관리하는 것을 trunk라 한다. 거기서 필요할 때만 브랜치를 분기하는 것을 trunk based flow라고 한다. 현업에서는 다양한 방식으로 브랜치를 관리하고 있는데, 그 중에서 가장 대표적인 방식인 git flow, github flow, gitlab flow 라는 3가지 관리 전략에 대해서 공부해보자.

1. Git flow

git flow 는 총 5 종류의 브랜치를 활용한다.

주의할 점은 master, develop은 각 브랜치가 영구적으로 존재하지만, hotfix, release, feature 브랜치의 경우 필요할 때마다 브랜치를 만들고, 머지가 되면 삭제한다는 점이다.

전체적인 merge 순서는 다음과 같다. (merge 할 때는 항상 —-no-ff 옵션을 붙이자!)

feature → develop → release → master

각각 브랜치의 특징에 대해 한 번 살펴보자.

• master(main)
  • 소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치
  • release 브랜치로부터 pull request 받음
  • 부모 브랜치: 존재하지 않음
  • 자식 브랜치: hotfix, develop
  • PR받는 브랜치 (pull request 받는 브랜치): release
  • PR나가는 브랜치 (pull request 보내는 브랜치): 존재하지 않음

 

• hotfix 브랜치
  • 배포된 서비스에 대한 긴급 버그 수정을 진행하는 브랜치.수정이 완료되면, develop 과 master 브랜치 각각에 pr 을 날림
  • 부모 브랜치: master
  • 자손 브랜치: 존재하지 않음
  • PR받는 브랜치: 존재하지 않음
  • PR나가는 브랜치: develop, master
  • hotfix 브랜치는 만들 때 hotfix-* (hotfix-1) 과 같은 형태로 이름을 지정해서 만든다

 

• release 브랜치
  • 배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치
  • release 브랜치는 만들 때 release-* (release-1) 과 같은 형태로 이름을 지정해서 만든다
  • 테스트가 정상적으로 완료되면, develop 과 master 브랜치 각각에 pr 을 날림. pr merge 가 완료되면, 브랜치를 삭제
  • 부모 브랜치: develop
  • 자손 브랜치: -
  • PR받는 브랜치: -
  • PR나가는 브랜치: develop, master

 

• develop 브랜치
  • 개발 단계의 코드가 있는 (개발의 중심) 브랜치
  • 개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 develop 브랜치로 pr 을 날립니다. 이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, develop 브랜치를 베이스로 해서 테스트를 위한 release 브랜치를 새롭게 만든다.
  • 부모 브랜치: master
  • 자손 브랜치: feature, release
  • PR받는 브랜치: feature
  • PR나가는 브랜치: -

 

• feature 브랜치
  • 특정한 기능 (단위 기능) 을 구현하는 브랜치
  • feature 브랜치는 만들 때 feature/* (feature/기능명) 과 같은 형태로 이름을 지정해서 만든다
  • 기능 구현이 완료되면, develop 브랜치로 pr 을 날림. merge 되면 브랜치는 삭제
  • 부모 브랜치: develop
  • 자손 브랜치: -
  • PR받는 브랜치: -
  • PR나가는 브랜치: develop

 

Git Flow 는 다음과 같은 경우에 유용하다

• 큰 규모의 팀
• 퀄리티 보장이 중요한 프로덕트
• release 된 프로덕트에 대한 관리 사이클이 긴 경우

 

 

2. Github Flow

Github Flow는 딱 2가지 종류의 브랜치만 사용한다.

Git Flow는 큰 규모의 팀 + 안정성이 매우 중요한 서비스에서 사용하면 좋지만, 작은 규모의 팀 + 빠른 개발과 업데이트가 중요한 서비스에서는 오히려 비효율적으로 작용한다.

그렇기 때문에 Github Flow는 단 2개의 브랜치만을 사용하며, 배포용 브랜치인 master, 각 단위 기능 구현을 위한 브랜치인 feature로 구성된다. feature 브랜치는 merge 후에 삭제된다.

• master(main)
  • 소비자가 사용하는 제품이 존재하는(배포될 코드가 있는) 브랜치(해당 브랜치는 push 받으면 자동으로 실제 서비스로 배포되도록 설정되어있음)
  • feature브랜치에서 단위 기능 구현이 완료될 때마다 pr을 받음(여기서 해당 브랜치를 merge 하기 전에 테스트를 진행)
  • 부모 브랜치: -
  • 자손 브랜치 (분기해서 생성되는 브랜치): feature
  • PR받는 브랜치 (pull request 받는 브랜치): feature
  • PR나가는 브랜치 (pull request 보내는 브랜치): -

 

• feature 브랜치
  • 특정한 기능 (단위 기능) 을 구현하는 브랜치
  • feature 브랜치는 만들 때 git flow 보다 더 구체적으로, 명확하게 작업명을 작성해서 만듦(단순히 feature/* 가 아니라 버그 해결인지, 기능 추가인지 등을 명확히 명시)
  • 기능 구현이 완료되면, master 브랜치로 pr을 날림. merge 되면 브랜치는 삭제
  • 부모 브랜치: master
  • 자손 브랜치 (분기해서 생성되는 브랜치): -
  • PR받는 브랜치 (pull request 받는 브랜치): -
  • PR나가는 브랜치 (pull request 보내는 브랜치): master

 

Github Flow 는 다음과 같은 경우에 유용하다.

• 작은 규모의 팀
• release 된 프로덕트에 대한 관리 사이클이 짧은 경우 (업데이트 주기가 짧은 경우)
• 빠른 배포와 관리가 필요한 경우

 

 

3. Gitlab Flow

Gitlab Flow 는 4종류의 브랜치를 사용한다.

github flow는 테스트를 위한 브랜치가 없고, 배포용 브랜치가 따로 없기 때문에 큰 규모의 서비스에는 적합하지 않다. 그래서 github flow 의 단순함과 git flow 의 체계적인 관리를 합쳐서 절충적으로 git 을 활용하는 방식이 바로 gitlab flow 입니다.

pre-production 브랜치가 테스트를 담당하고, master 브랜치가 개발용 브랜치로 역할한다. feature 브랜치는 다른 flow 와 마찬가지로 merge 되면 삭제된다.

• production 브랜치
  • 소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치
  • pre-production 브랜치로부터 pull request 받음
  • 부모 브랜치: master
  • 자손 브랜치 (분기해서 생성되는 브랜치): -
  • PR받는 브랜치 (pull request 받는 브랜치): pre-production
  • PR나가는 브랜치 (pull request 보내는 브랜치): -

 

• pre-production 브랜치
  • 배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치
  • 테스트가 정상적으로 완료되면, production 과 master 에 각각 pr 을 날림
  • 부모 브랜치: master
  • 자손 브랜치: -
  • PR받는 브랜치: master
  • PR나가는 브랜치: production, master

 

• master(main)
  • 개발 단계의 코드가 있는 (개발의 중심) 브랜치
  • 개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 master 브랜치가 pr 을 받음. 이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, pre-production 으로 pr 을 날림.
  • 부모 브랜치: -
  • 자손 브랜치: feature
  • PR받는 브랜치: feature, pre-production
  • PR나가는 브랜치: pre-production

 

• feature 브랜치
  • 특정한 기능 (단위 기능) 을 구현하는 브랜치
  • 브랜치명은 github flow 처럼 자세하게 작성합니다.
  • 기능 구현이 완료되면, master 브랜치로 pr을 날림. merge 되면 브랜치는 삭제됨
  • 부모 브랜치: master
  • 자손 브랜치: -
  • PR받는 브랜치: -
  • PR나가는 브랜치: master

 

Gitlab Flow 는 다음과 같은 경우에 유용하다.

• 중간 규모의 팀
• 퀄리티 보장이 중요한 프로덕트
• 빠른 배포와 관리가 필요한 경우

 

- commit convention 정하기

커밋 메세지란 커밋을 할 때, 현재 commit 이 정확히 무엇과 관련한 개발에 해당하고, 어떤 변경 사항이 있는지 등을 작성하는 것을 말함

커밋 메세지를 잘 작성하면, 우리는 단순히 커밋 이력만 보고서도 현재까지 어떤 개발이 진행되었고, 어떤 커밋에서 문제가 발생했는지 등을 확인할 수 있게 된다. 특히나 규모가 큰 개발일수록 이 커밋 메세지는 더욱 중요해진다.

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

또한 커밋메시지에 본문, 꼬리말을 달아 issue를 닫을 수도 있다.

꼬리말은 다음과 같은 형식으로 작성한다.

Close: #123

유형은 “Close, Fix, Resolve” 등을 활용 (보통 Close 는 일반 개발 이슈를 닫을 때, Fix 는 버그 이슈를 닫을 때, Resolve 는 문의나 요청사항에 대한 이슈를 닫을 때 사용한다)

 

 

- issue, pull request template 등 만들어보기

template 란 issue나 pull request를 작성하기 위한 틀을 말한다.

우리가 issue나 pull request를 작성할 때 일일이 목차를 직접 작성하게 되면 시간이 오래 걸리기 때문에, 이미 목차가 있는 template을 활용해서 작성하면 훨씬 더 시간을 단축할 수 있다.

그리고 혹시나 팀원들 간에 양식을 지키지 않고 issue 나 pr 을 작성하게 되는 경우도 방지할 수 있다. issue 의 경우도 앞서 commit message 처럼, 타입과 함께 작성하는 것이 훨씬 더 가독성이 좋다.

 

이부분은 실습을 통해 팀원들과 진행해보았다.

우선 git 으로 관리되는 폴더 내부에, .github 폴더를 만들었다.

해당 폴더 내에 다음과 같이 issue_template.md, pull_request_template.md 파일을 만들어주었다.

pull_request_template.md

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


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


## 스크린샷


## 테스트 결과


## 리뷰 요청 사항

issue_template.md

## 목적


## 세부 내용

이렇게 작성하고 메인 브랜치에 푸시하고 새로운 이슈를 생성하면

issue_template 에 작성해놓은 대로 표시되는 것을 볼 수 있다.

이렇게 내가 아까 만들어놓은 양식에 따라 issue, pr을 팀원들이 적어주어 merge를 해 실습을 마쳤다.

 

 

 

나는 프로젝트를 진행할 때 커밋 컨벤션을 정하지 않고 시작해, 팀원들과 커밋 메시지가 다 달라서 알아보기 힘들었던 적이 있는데, 앞으로는 커밋 컨벤션을 정해 가독성을 높여야겠다.

그리고 강의에서 main 브랜치에 바로 push 하는 행위는 매우 위험하다고 했는데, 이전에 프로젝트를 진행할 때 팀원과 각각 브랜치 하나씩만 파고 계속 main 브랜치에 push했던 경험이 있다. 300번이 넘는 커밋을 했는데 위험한 줄도 모르고 main 브랜치에 바로 push했는데 이제부터는 branch protection을 사용해 main 브랜치에 바로 push 못하게 해야겠다.

 

** main 브랜치에 바로 push하면 위험한 이유 **

만약 주니어 개발자가 에러가 나는 코드를 잘못해서 바로 main 브랜치에 push 하게 되면 어떻게 될까?

서비스 사용자는 서비스를 이용하다가 난데없이 에러를 마주하게 될 것.

(지금 우리한테는 에러가 별일 아니지만, 실제 서비스라면 에러가 발생함에 따라 법적인 분쟁까지 이어질 수도 있음.)

아무리 신입 개발자한테 main 브랜치에 push 하지 말라고 교육해도, 분명 실수를 할 수 있기 때문에 우리는 push 할 권한 자체를 없애버려야 한다고 한다.