~ 오늘은 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 clonebranch 생성하여 작업

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를 보고서 바로 알았어야 했는데 시간이 지난 다음에야 알아챈 게 조금 아쉬운 부분이었다.
그래도 스스로 알아낸 게 어디인가 싶다.

다음부터는 꼼꼼하게 보는 것으로.

0개의 댓글