경일게임아카데미 멀티 디바이스 메타버스 플랫폼 개발자 양성과정 20220420 2022/04/04~2022/12/13

경일 메타버스 20220420 3주차 3일 수업내용. 실제 Git 사용 - 원격, 팀프로젝트 실습

실제로 사용해보니 아직 Git을 완벽히 이해 못했다는 걸 알았다. 앞으로 팀 프로젝트를 계속하며 익숙해져야겠다.

주의사항

• vim editor 사용 주의
• vi 파일명으로 열 것.
• 파일명을 적기 깜빡했다면, :wq 파일명으로 파일명 지정 가능.
• git log 사용 주의
• 너무 길면 q, w, e로 표시 조절 가능
• e : 아래로 / w : 위로 / q : 나가기

Git 원격 실사용

git remote 이름 URL : Github 등의 원격 저장소와 연결. 원격 저장소의 이름은 관습적으로 origin을 많이 쓴다.
git remote : 현재 원격 저장소의 이름을 표시한다.
push를 해보면 Token 값을 넣을 수 있는 창이 뜬다. Github에 들어가서 사용자 settings에서, 맨 밑 developers setting으로 들어가서 personal access token에서 generate new token을 하면 일회용 접근 티켓 격인 Token을 받을 수 있다. 토큰을 앞의 창에 넣으면 접근 자격 획득. 이 토큰은 남에게 공유를 하면 안된다!

• Github UI 설명
• fork : 다른 사람 레포지토리를 복사해서 작업 후 돌려주기 가능
• star : 좋아요 같은 느낌. 그 의미는 더욱 무거워서, 정말 가치가 있다고 생각하는 것에만 눌러주는 문화가 있다.

unix 명령어

rm -rf 폴더명 : 재귀적으로(-r), 강제적으로(-f) 폴더를 삭제한다. 강제적 삭제이므로 매우 조심할 것.

git clone https://(토큰 주소)@(깃허브 주소) : 토큰을 사용해 보안을 강화하기 위한 클론 방법.
git config —local user.name “” : 로컬 유저 네임 지정
git config —local user.email “” : 로컬 이메일 지정

• 클론하거나 레포지토리를 작성할 때마다 새로 위의 두 개를 지정하고 자리를 옮기면 삭제할 것.

협업에서 브랜치를 잘 관리하기 위한 방법 / 전략

Git Flow / Github Flow / Gitlab Flow
GIthub Flow
1. main 브랜치는 항상 안정적이고 최신의 상태여야 한다. 실수로 main 브랜치에 푸시하지 않도록 주의한다.
2. 브랜치 이름은 다른 사람이 봐도 어떤 작업인지 한눈에 알 수 있도록 명확히 이름을 짓는다.
3. 원격에도 자주 푸시해 어떤 작업을 하는지 다른 사람에게 공유한다.
4. 피드백이나 도움이 필요한 경우 혹은 병합할 준비가 됐다면 Pull Request를 연다. Pull Request는 코드 리뷰를 도와주는 시스템으로 어떤 변화가 있는지 확인할 수 있고, 코드에 대해 토론할 수 있으며, 간단한 충돌도 해결할 수 있다.
5. 팀원들과 충분한 논의를 거친 후에 main으로 병합할 수 있도록 한다.
6. (Advanced) main에 푸시 됐거나 병합된 것은 즉각 배포되어야 한다. CI/CD : 지속적 통합/지속적 제공

협업에서 충돌을 줄이기 위한 규칙

1. main 브랜치에서 기능 관련 브랜치를 만들고 체크아웃한다.

2. 기능을 개발할 때마다 커밋하면서 푸시를 한다.
   2-1. 개발 및 커밋하기 전 git fetch를 통해서 원격 저장소를 항상 최신화한다.
   2-2. main에 새로운 기능이 추가되었다면 내 브랜치로 병합한다.
   2-3. 커밋하기 전 항상 내 코드를 스스로 리뷰한다.

3. 기능 개발이 끝났다면 Pull Request를 연다.
   3-1. Pull Request 도중 충돌이 발생했을 경우 로컬에서 충돌 해결한 다음 푸시한다.

4. 다른 사람들한테 Pull Request를 열었다고 알려준다.

5. 해당 팀원의 코드를 리뷰한다.

6. 리뷰가 끝났다면 병합한다.

7. 병합이 끝나면 원격 브랜치를 삭제한다.

Github 기능 - Branch Protection Rule : 특정 브랜치를 보호할 수 있는 기능을 설정 가능.

• Require a pull request before merging
• Require approvals : 전체 팀원 - 1 만큼 설정.
• Require review from Code Owners : 팀장(레포지토리 주인)의 리뷰를 반드시 받아야 한다.
• Include administrator : 팀장도 리뷰를 받아야 한다.

주로 쓰이는 Git GUI : Github Desktop, SourceTree, TortoiseGit, GitKraken, Tower

이번 실습 : SourceTree 사용

• GUI는 global 설정 필수
• GUI는 git-flow 같은 전략을 지원한다는 점에서 좋다.
  • 사실 Visual Studio도, vs code도 Git을 지원한다. - 메뉴의 Git이나 Extension

커밋 메시지 컨벤션 (관습)

• 타입과 제목은 필수
• 타입[범위]: 제목 [본문][꼬릿말]
• 타입
  1. Feat: 새로운 기능의 추가
  2. Fix: 버그 수정
  3. Docs: 문서 수정
  4. Style: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
  5. Refactor: 코드 리펙토링
  6. Chore: 빌드 업무 수정, 패키지 매니저 수정 등 잡다한 일(ex .gitignore 수정 같은 경우)

제목

• 명령문을 사용하며 50자 이내로 제한한다. 끝에 마침표를 적지 않도록 주의한다.
• https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

본문

• 본문은 구현 방법보다는 변경한 내용과 이유를 설명한다. 한 줄 당 72자 내로 작성하며 양에 구애받지 않고 최대한 상세히 작성한다.

꼬릿말

• 선택사항으로 보통 Github Issue 추적을 위해 사용한다. “유형: #이슈 번호” 형식을 사용하며, 여러 개의 이슈 번호를 적을 때는 쉼표로 구분한다. 유형은 Resolves, See also를 사용한다.
• 이슈(Issue) : 보통 뭐가 안돼서 도움이 필요한지. https://docs.github.com/en/issues

Request된 커밋의 리뷰 → Files changed → 코멘트 가능, viewed 체크 가능 → progress바의 변화 → 코멘트의 타입 - Comment (첨언) / Approve (동의, 찬성) / Request changes (반드시 변화 필요)

• Pull Request가 열렸다고 해도 커밋은 할 수 있다.
• GUI 툴에서 staged된 커밋을 더블 클릭하면 변경 사항을 확인할 수 있다.
• 푸쉬 전에 자신의 코드는 항상 최선을 다해 퀄리티를 높일 것. 자신의 코드는 자신이 책임져야 한다.
• SourceTree에서도, VS에서도 충돌 처리를 지원한다.

오늘 Git 실습에서 반 안에서 일어난 오류들

1. main 직접 푸시하는 경우 있음. => 꼭 브랜치 만들기

2. fetch하고 진행할 것.

3. Merge Pull Request 대신에 Close Pull Request

4. Push != Pull Request. Push를 한다고 Pull Request가 되는 건 아님.

5. Pull Request를 병합한 뒤에 Delete Branch를 하는데 이거는 Remote Branch만 삭제함. Local Branch는 아님.

6. Pull Request는 브랜치 하나당 하나만 열 수 있음.