4일차. Git 관리 전략을 활용한 협업

목차

1. Git 관리 전략
2. Git 사용 팁
3. Github 활용한 협업

 

하나의 중심 브랜치 전략 : trunk

필요시에 분기하는 가장 기본적인 전략 : trunk based flow (trunk at scale)

 

• 사용할 브랜치를 미리 생성해두는 전략 (굵게 표시한 브랜치는 merge되어도 영구적으로 사용하는 브랜치) 
  • master : 실제 서비스를 하고 있는 브랜치
  • hotfix : 메인 브랜치에서 분기해 심각한 오류를 해결하기 위한 브랜치
  • release : 품질검사를 위해 생성하는 브랜치
  • develop : 개발을 위한 브랜치
  • feature : develop에서 분기한 기능 개발용

---

1. Git 관리 전략

 

1) Git 관리 전략 종류

규모 / 릴리즈 주기에 따라 관리 전략을 선택한다.

 

1. Gitflow :가장 이상적인 (복잡한) 관리 전략으로 대규모 팀에서 사용한다.

master, hotfix, release, develop, feature

:안정성 최대

 

2. Githubflow : 개발자 중심의 소규모 팀에서 안정성이 매우 중요한 서비스, 릴리즈 주기가 짧을 때 사용한다. (auto deploy 자동배포)

main, feature

-> feature 브랜치 명명시, 구체적인 이름을 명시한다.

:생산성 최대

 

3. Gitlab flow : 중간 규모로, 안정성과 생산성을 모두 잡은 관리 전략

• production : 메인 서버
• pre-production : 베타 서버
• master : 개발 단계의 코드
• feature : 기능 개발 서버

production, pre-production, master, feature
:중간 생산성과 중간 안정성을 채택

 

2) git commit convention 수립

 

커밋 메시지 규칙

제목 포괄적 작성

본문 세부적 작성

꼬리말 close, fix, resolve 등등 : 이슈명

 

커밋 메시지 타입 규칙 설정

: Feat, fix, Style, Comment, Docs, Test, Rename, Remove 등등

 

일반적인 작성 방식 (Close할 이슈를 적는 위치)

1. 커밋 메시지에서 상세히 적는 경우

2. pull request에서 상세히 적는 경우 (커밋을 한 번했을 경우 pull request에서 해당 커밋 메시지의 제목과 본문을 가져온다.)

 

커밋이 여러번 될 수 있으므로 pull request에서 close를 하는 것이 더 이상적이다.

 

3) issue, pull request template 생성

.github 폴더에 템플릿을 생성한다.

리포지토리 생성시 가장 기본적으로 생성

 

 

pull을 할 경우 발생하는 에러

힌트: You have divergent branches and need to specify how to reconcile them.
힌트: You can do so by running one of the following commands sometime before
힌트: your next pull:
힌트: 
힌트:   git config pull.rebase false  # merge
힌트:   git config pull.rebase true   # rebase
힌트:   git config pull.ff only       # fast-forward only
힌트: 
힌트: You can replace "git config" with "git config --global" to set a default
힌트: preference for all repositories. You can also pass --rebase, --no-rebase,
힌트: or --ff-only on the command line to override the configured default per
힌트: invocation.

: 원격 저장소의 커밋 기록과 로컬 저장소의 커밋 기록이 다를 경우 발생

 

-> git pull을 하면 원격 저장소의 기록을 merge하는 것과 같다.

-> 어떤 커밋 기록을 이용해 merge할지 명시를 해줘야 한다.

git pull origin main --no-ff

 

 

이슈의 종류마다 템플릿을 설정할 수도 있다.

: setting - features - issue

 

github에서 제공하는 템플릿

• Bug report
• Feature request

 

 

 

 

 

4) branch protection

main 브랜치에 바로 push를 하지 못하게 방지하는 기능

코드 리뷰를 수행 후에, 푸시를 할 수 있도록 브랜치를 안전하게 관리하는 기능

 

Settings - Branches - Default branch 설정과 Branch protection rules 설정

 

 

Branch protection rules 설정

-Branch name pattern : 특정 브랜치 뿐만 아니라, '*' (와일드 카드)를 활용해 설정 가능

-8가지 룰

1. merge 이전에 pull request 가 필요 (pull request 를 통해서만 해당 브랜치로 merge 가능)
   • 코드 리뷰시 Approval의 개수에 따라 허용할지 등등
2. 테스트 결과 (status check) 이상이 없을 시에만 merge 가능
3. 코드 리뷰에 달린 conversation 이 모두 해결 (resolve) 된 경우에만 merge 가능
4. 커밋이 sign 되어있어야함 (gpg key 를 가지고 commit 한 경우만 허용)
5. 분기되지 않고 선형 이력을 가져야 함 (merge commit 자체가 불가능 → 즉, 하나의 이력으로 정리된 경우만 허용)
6. 배포가 성공한 경우에만 merge 가능 (특정 브랜치를 deploy 용으로 환경을 만들어놓은 경우에만 의미가 있음)
7. 특정 브랜치에 푸시를 못하게 락을 거는 기능
8. 그 누구도 위 보호 옵션을 우회 (bypass) 할 수 없음 (심지어 github repo 관리자도)

 

 

관리자 포함해 모두에게 허용하는 옵션 (안정성을 해치는 절대 금지 옵션)

-강제 푸시 허용

-강제 삭제 허용

 

 

---

2. Git 사용 팁

 

.gitignore

민감 정보를 기록한 파일을 숨기는 기능

 

git rm -r --cached (지울 파일)

이미 commit 한 경우, 캐시를 지운다.

 

---

3. Github 활용한 협업

협업 후 보완해야할 사항 정리

 

1. 프로젝트 팀원 소개란

• 표로 작성해 각각의 팀원의 깃허브로 연결

2. 머지한 브런치는 삭제

3. pull request의 경우 체크박스를 활용

• 이슈에 필요한 해결사항 작성 후, 해당 사항을 이용해 pull request에서 체크박스로 해결여부 작성

4. files changed -review changes -코드리뷰 진행

• 코멘트 뿐만 아니라 실제 코드리뷰 진행

5. wiki에 커밋 컨벤션 규칙과 이슈 규칙 정의

 

리포지토리 생성시 확인해야할 사항

(1) git 관리 전략 (flow) 선정
(2) commit convention
(3) issue/pr template issue label 생성
(4) 제외할 민감 정보 파일 설정
(5) push/merge rule
(6) 템플릿 생성