깃 프로그램은 깃허브 데스크탑이나 포크가 있음
특강 멘토님은 포크를 사용한다고 함
맥에서 많이 사용하는 것 같음

GIT

GIT은 "협업을 위한" 도구

1. 깃허브를 왜 써야하는가?

협업할 수 있는 능력을 증명
경쟁력
코드 공개

2. 깃허브의 올바른 사용법

아카이브의 형식은 좋지 않은 사용법임
완벽한 코드가 아니더라도 커뮤니케이션, 성장 과정을 보여주는 것도 중요

3. 깃의 기본 기능

commit

기록을 남기는 것
코드를 저장 및 내용을 포함하여 기록

repository(원격 저장소)

Github의 원격저장소(repository)에서 내 컴퓨터(local)로 pull 하거나
내 컴퓨터(local)에서 Github의 원격저장소(repository)로 push

push

원격 저장소(서버)에 내 코드를 업로드

pull

원격 저장소(서버)에서 내 코드를 다운로드

branch

작업 공간을 나누는 것

4. 깃허브 쉽게 쓰기

5. Code Review(with 이슈관리, PR)

코드 리뷰의 장점

• 코드 상의 실수를 미리 파악할 수 있다.
• 책임이 줄어든다.
• 개발자로써 기술적 성장이 쉽다.
• 커뮤니케이션 능력이 늘어난다.
  등등

깃허브의 협업 도구로써의 강점

Issue

현업에서는 한 기능에 여러명이 모여서 작업을 하기도 해서
기능 단위로 나눠야 Issue를 발행하기 좋음

요구사항에 어떤 기능을 만들지 상세하게 적어놓기

Pull Request(PR)

고민한점, 추후 수정되어야 하는 부분등을 상세하게 적어주기
스크린샷도 추가할 수 있다

Approve : merging에 동의
Request changes : merging을 재고, 보통은 Comment로 해줌

코드리뷰를 잘 작성하기 위한 가이드

• 친절하게 코멘트
• 코드의 수정량이 +-를 합쳐서 500줄이 넘지 않도록
• 사소해보이더라도 남기는 연습(Nit: ~~~)
• 이해가 안가는 코드는 질문으로 코멘트를 남기기
• 칭찬의 코멘트

6. 깃허브 컨벤션

커밋 컨벤션

feat : 새로운 기능을 추가할 경우
fix : 버그를 고친 경우
docs : 문서 수정한 경우
style : 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는 경우
refactor : 코드 리팩터링
test : 테스트 추가, 테스트 리팩터링

[커밋 타입] : [#이슈 번호] [커밋 내용]
ex1) feat: #16 로또 번호 랜덤 생성 추가

그 외
Add
Modifier
Fix
Refactor
등등

gitmoji

7. 깃을 혼자 사용할 때는?

협업과 마찬가지로 혼자 사용할 때에도 동일하게 컨벤션을 정해주면 좋다.

QNA

push할때는 merge를 pull할때는 rebase를 주로 한다고 함