Git & GitHub

Speaker
- 올해 1월, 법인 설립 준비 중인 회사(?)에 1호 개발자로 합류
- 전) 헬스케어 스타트업, B2B 패션 스타트업 서버 개발
- 전) 웹 프론트엔드 개발 / 개발 프리랜서
-
특이사항?
- 프로그래머스 프론트엔드 데브코스 1~4기 멘토
김동영

진행 안내
- 질문은 전달드린 slido에 남겨주세요.
Git을 사용할 이유
Git이 등장한 배경
Linus Torvalds

버전 관리 시스템을 사용하지 않는 버전 관리
버전 관리 시스템을 사용하지 않는 버전 관리
- 소스 코드들은 어떻게 관리할 거에요?
- 의존 패키지, 라이브러리는요?
- 물론 가능'은' 합니다.
- diff + patch 같은 도구를 통해서요
- = 버전 관리 지옥
버전 관리 + 시스템
- 변경된 내용의 기록
- 특정 시점을 명명 (reference, tag, version)
- 오늘, 어제, 데브코스 시작일
- 수정 내역을 추적
- 이전 상태로 되돌림
주변에 있는 버전 관리 시스템






버전 관리 시스템

그 중에서도 Git
- 비교적 가장 최근에 등장한(2005) 버전 관리 시스템
- 많은 기능을 제공하고, 대중화되어 있다. 사실상의 표준 (de facto)
- 대부분의 경우 합리적이다.
- 그러나 대규모 코드 베이스를 다뤄야 하는 경우 발생하는 성능 문제
- https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/
- https://graphite.dev/blog/why-facebook-doesnt-use-git
Git을 잘 다룰 수 있으면 좋은 점?
- 사용하는 기술 스택(언어 4번, 프레임워크 6번)이 변화하는 와중에도 변하지 않는 도구



Git 시작하기
Git Clients
- GitKraken (유료)
- Sourcetree (무료)
- IDE 내장 (VSCode, WebStorm, …)
- GitLens
- Git Graph
- … 너무 많아요
Git 설정
git config --global user.email "<email>"
git config --global user.name "<name>"
git config --global --list
git config --global --editGit 저장소 만들기
git init [<directory>]
# or
git clone <repository> [<directory>]
git statusCommit
> '의미' 있는 변화
- 커밋은 언제 해야 할까요?
- e.g.
- React 프로젝트 생성
- 회원 인증 기능 추가
- 버튼 클릭 버그 수정
- 리렌더링 최적화

Staging Area
git add
git commit
Branch
> '작업'의 분기점
- 브랜치는 언제 만들어야 하나요?
- e.g.
- (막연하게는) 새로운 작업을 시작하기 전
- issue가 나에게 할당된 후
- 이 시점을 백업(아카이빙)해두고 싶을 때
- 새로운 버전을 출시하기 전
Merge
> 나뉘어진 분기의 '통합'

Conflict (충돌)
- 발생 이유
- 동일한 영역이 서로 다른 시간에 수정됐을 때
(Git이 자동으로 해결할 수 없는 충돌인 경우)
- 동일한 영역이 서로 다른 시간에 수정됐을 때
- 대처 방법
- 충돌이 발생한 원인을 파악한 후 충돌이 발생한 파일을 수정한다.
- 충돌 시점(어떤 커밋, 어떤 액션)
- 충돌 유형(기능 추가, 리팩터링, 코드 스타일 수정)
- 충돌 위치(파일과 라인)
- 충돌이 발생한 원인을 파악한 후 충돌이 발생한 파일을 수정한다.
Git 명령어 파레토 법칙
> 커맨드 중 20%가 사용량의 80%를 차지한다.
- init, clone
- status, log
- add, commit
- branch, checkout (switch / restore)
- push, pull
- merge, rebase
- revert, reset
Git vs GitHub



버전 관리 시스템

버전 관리 시스템
분산
Repository
저장소
Local
Repository
Remote
Repository

commit
push
pull
sync
중앙집중식(Centralized) VCS
repo
분산(Distributed) VCS
repo
repo
repo
repo
remote
local
GitHub에서 제공하는 기능들
- Pull Requests (PR)
- Code Review
- Issues + Discussions
- Labels
- Projects & Milestones
- Wikis
- GitHub Actions (CI/CD)
Pull Request 활용
- Pull Request 생성할 때 부연 설명을 작성할 수 있다.
- 템플릿을 활용한 내용 구조화가 가능하다.
- 생성된 Pull Request에서 코멘트와 리뷰를 남길 수 있다.
- 히스토리 추적과 파악을 용이하게 만들 수 있다.
- 오픈소스에 기여할 때 항상 사용한다.
Git이 동작하는 구조
Git Object Model
- SHA-1 Hash
- Blob
- Tree
- Commit
- Tag
Git Object Model
ls -al .git
echo "Hello, World!" | git hash-object -w --stdin
git cat-file -t <object>
git cat-file -p <object>Git Object Model
git log
git rev-list --parents -n 1 <commit>
--
git ls-tree HEADRepository 관리 전략
Centralized
Forking


Centralized
repo
repo
repo
repo
Forking
repo
repo
repo
repo
repo
repo
repo
upstream
local
origin
Branching Workflow
- Git Flow
- main, develop, release, feature, hotfix
- GitHub Flow
- main, feature
- GitLab Flow
- main, stable, production
- Trunk-based
- only trunk
Git Commands
Git Commands
clone
stash
commit
tag
checkout
init
show
add
diff
branch
config
status
log
restore
submodule
switch
archive
merge
reflog
rm
pull
gc
clean
rebase
remote
mv
reset
cherry-pick
revert
push
fetch
개인 저장소
로컬 저장소
clone
fork
Remote
Local
그룹 저장소
upstream
origin
개인 저장소
로컬 저장소
clone
fork
Remote
Local
그룹 저장소
upstream
origin
commit
push
PR
fork
PR
pull
Git & GitHub
By Dong-Young Kim
Git & GitHub
- 168

