~ 오늘은 4일차 ~
- 목차
1. Git 관리 전략
2. Git Commit Convention
3. Issue, Pull Request Template
4. Branch Protection
5. git pull 시 발생하는 에러 해결
6. .gitignore 로 key 파일 제외 ★
7. Git 협업 최종 정리
+ 복기일기
1. Git 관리 전략
-
git flow, github flow, gitlab flow
-
trunk : 기본적으로 하나의 중심 브랜치로만 관리하는 것
-> 보통 소규모에서 사용
(1) git flow
- 5종류의 브랜치 (master, hotfix, release, develop, feature)
- 큰 규모의 팀, 퀄리티 보장 & 안정성이 중요한 프로덕트에 활용
- hotfix : 긴급 버그 수정, master에서 파생
hotfix-* (hotfix-1)- release : QA 브랜치, develop에서 파생
release-* (release-1)-> 둘 다 수정 완료 후 develop 과 master 브랜치에 각각 pr 날리기
(2) github flow
- 2종류의 브랜치 (master, feature)
- 소규모의 팀, 빠른 개발과 업데이트가 중요한 경우
(3) gitlab flow
- 4종류의 브랜치 (production, pre-production, master, feature)
- 중간 규모의 팀, 퀄리티 보장 필요, 빠른 배포와 관리가 필요한 경우
- pre-production 브랜치가 테스트를 담당, master 브랜치가 개발용 브랜치로 역할
2. Git Commit Convention
(1) -m 으로 간단하게 작성
Feat: "로그인 함수 추가"
로그인 요청을 위한 함수 구현
Closes: #123(2) git comit으로 전체 작성
Feat: "로그인 함수 추가"
로그인 기능 구현을 위해 로그인 요청을 보내는 axios 함수 작성
Close: #123
①
-m”내용”으로 작성한 것은 제목이며,git commit만 입력 시 전체 작성이 가능
② 제목은 “타입: 내용” 형식으로 작성
③ 본문은무엇을,왜라는 내용을 포함
④ 꼬리말은 "유형: 이슈번호" 형식으로 작성
⑤ 꼬리말에서 close #이슈번호를 사용해 이슈를 닫기
(3) 타입의 예시
- Feat : 새로운 기능 추가
- Fix : 버그 수정
- Env : 개발 환경 관련 설정
- Style : 코드 스타일 수정 (세미 콜론, 인덴트 등의 스타일적인 부분만)
- Refactor : 코드 리팩토링 (더 효율적인 코드로 변경 등)
- Design : CSS 등 디자인 추가/수정
- Comment : 주석 추가/수정
- Docs : 내부 문서 추가/수정
- Test : 테스트 추가/수정
3. Issue, Pull Request Template
(1) VS코드에서 만들기
① .github 폴더와 issue_template.md, pull_request_template.md 파일 생성
② pull_request_template.md
## 작업 개요 (이슈 번호)
## 작업 내용 (변경 사항)
## 스크린샷
## 테스트 결과
## 리뷰 요청 사항③ issue_template.md
## 목적
## 세부 내용④ 반드시 main 브랜치로 push
git add .
git commit -m"Docs: Add templates"
git push origin main(2) Github에서 추가하기
① repo -> 설정 -> set up templates
② preview and edit로 알맞게 수정 후 사용
4. Branch Protection
- main에 바로 push하면 위험하기 때문에
이를 방지하기 위해 github에서 사용하는 방식(1) repo -> 설정 -> Branches -> Add rules
(2)Branch name pattern에 보호할 브랜치명 작성
->feature*라고 작성 시,feature라는 접두어를 가진 모든 브랜치에 적용
(3) 아직은 아래의 목록 정도만 사용해도 좋다. (또는 ①,⑦)
① Require a pull request before merging
③ Require conversation resolution before merging
⑦ Do not allow bypassing the above settings
5. git pull 시 발생하는 에러 해결
(1) git pull 의 근본적인 원리
github 쪽의 브랜치와 내 컴퓨터의 브랜치를 merge 혹은 rebase 를 통해 합치는 것으로 이루어진다.
그러나 아래의 에러는 git 이 pull 을 할 때 정확히 merge, rebase 혹은 fast-forward merge 중에 무엇을 선택해야할지 모르겠으니 사용자에게 지정해달라고 말하는 것.
(2) 에러메세지와 해결
you have divergent branches and need to specify how to reconcile them.
(이하 생략)- 나의 로컬 브랜치의 커밋 이력과, 리모트 브랜치 (github 쪽) 의 커밋 이력이 충돌하는 경우 발생
- git 설정 자체를 바꾸는
git config pull.rebase false보다는
git pull origin main --no-ff같이 정확히 내가 원하는 pull형태가 어떤 것인지 지정해주는 것이 좋다.
★ ★ ★
6. .gitignore 로 key 파일 제외 ★
- 암호 파일을 프로젝트 폴더 내부에 관리해야 할 때 사용 가능
(1) 프로젝트 폴더 내부에서 특정한 파일만 제외하고 싶을 때
①
.gitignore파일 생성 후 내부에 제외하고자 하는 파일 or 폴더명 작성
② 제대로 제외된다면 vs코드 내에서 회색 처리
(2) 만약 이미 key 파일을 add,commit 했을 경우
- 이 때에는 이미 파일이 cache안에 남아있어 제외되지 않는다.
git rm -r --cached .실행
-> 임시저장소(cache)에서 삭제되고,.gitignore정상 작동
7. Git 협업 최종 정리
(1) Git 협업 프로세스
① 팀의 git 관리 전략 flow, commit convention, issue/pr template, issue label 정하기
② 팀장이 해당 template 등을 적용한 github repo 를 생성
③ 앞으로 구현할 작업을 기능 단위로 세분화 후 분담
④ 담당자들은 기능에 대한 issue 생성, 팀장은 milestone 생성
⑤ 팀장은 github repo 에 최초 commit/push 진행 후 branch protection 설정
(merge conflic 방지를 위해 파일/폴더 트리를 생성한 다음 최초의 push를 진행하는 것이 좋다.)
⑥ 팀원은 repo clone 후 branch 생성하여 작업
⑦ pull request 후에
① 코드리뷰 작성 ② 수정사항 모두 해결되면 ③ approval 코드 리뷰
⑧ 팀장은 approval 코드 리뷰가 있는 pull request 에 대해 merge
(2) wiki 내용 정리
-
git 관리 전략 (flow)
-
commit convention
-
branch name
-
commit message type
-
issue label
-
issue name
-
issue/pr template
(3) clone 방법
git clone > cd (폴더) !!꼭 해당 폴더로 진입 !! > develop 브랜치 선택 > 브랜치 생성 > add, commit진행 > git push origin (브랜치명)
+ 복기일기
문제점 복기를 시작해보자.
오늘 이야기 할 내용은 2가지가 있고, 어느정도 이어지는 내용이다.
1.
오늘은 Git&Github 마지막 강의였다.
강의 자료를 봤을 때는 이전보다 분량이 훨씬 적다 생각했는데, 마지막 최종 협업 실습에서 갈피를 못 잡고 결국 시간 내에 완료하지 못했다.
이번 강의에서는 에러라고 부르기에는 민망한 버벅거림 뿐이었다.
내가 조장이었기에 다른 팀원들이 내 작업 만을 기다리고 있다는 것에 나도 모르게 조바심을 내느라 마음만 앞섰었다.
물론, 조원 모두 같이 조율하며 내용을 정하는 과정 자체에 시간을 많이 들였던 터라 온전히 내 작업의 딜레이 때문이라 부를 수는 없었지만 말이다.
비록 시간 내에 완성은 못했지만 이렇게 이야기하고 다 같이 정하는 과정 자체는 사실 난 재미있게 느껴졌다. 다들 원하는 방향성을 말하고 하나하나 완성할 때마다 퀴즈를 푸는 듯 즐거웠기에 완성을 못한 것에 큰 좌절을 느끼진 않는다.
그리고 내일이 되면 다시 자체적으로 모여서 더 탄탄하게 해보자는 의견들이 있어 끝이라고 생각하지도 않는다.
2.
그렇게 시간초과로 실습을 겨우 마무리 하고난 뒤.
한 조원 분이 repo를 clone하는 과정에서 문제가 생겼다며 DM을 주셔서 둘이서 머리를 맞대고 이야기 할 기회가 생겼다.
- 에러 내용
main과 develop 브랜치가 생성 된 repo를 새로운 vs코드에 clone했으나, branch 목록에 main만 보이며 develop이 보이지 않음
처음에 우리가 생각한 문제의 원인은 다음과 같았다.
① 혹시 clone할 때 repo 주소가 branch 별로 나눠져 있나?
-> no / 당연히 하나다.② 내가 push 해놓은 원격 저장소가 잘못 되었나?
-> no / 다른 팀원들은 develop이 정상적으로 보였다.③ 새로운 폴더가 아닌가?
-> 몇번을 만들어도 동일했다.
여기까지 왔을 때,
계속 눈에 밟히던 강의자료 내용이 있었다.
(클론 진행 시 이미 git 으로 관리되고 있는 폴더 내부에 만드시면 안됩니다!)
그러했다.
조원분의 vscode를 다시 보니, 새 폴더를 만들면서도 clone 전, 처음에 git init을 찍었던 것.
둘이서 50분 가까이 하던 토의는 그렇게 속 시원히 끝났다.
마무리
복습은 해도해도 부족한 듯 싶다. 처음에 vscode를 보고서 바로 알았어야 했는데 시간이 지난 다음에야 알아챈 게 조금 아쉬운 부분이었다.
그래도 스스로 알아낸 게 어디인가 싶다.
다음부터는 꼼꼼하게 보는 것으로.
