Git & GitHub

Speaker

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

김동영

진행 안내

  • 질문은 전달드린 slido에 남겨주세요.

Git을 사용할 이유

Git이 등장한 배경

Linus Torvalds

버전 관리 시스템을 사용하지 않는 버전 관리

버전 관리 시스템을 사용하지 않는 버전 관리

  • 소스 코드들은 어떻게 관리할 거에요?
  • 의존 패키지, 라이브러리는요?
  • 물론 가능'은' 합니다.
    • diff + patch 같은 도구를 통해서요
    • = 버전 관리 지옥

버전 관리 + 시스템

  • 변경된 내용의 기록
  • 특정 시점을 명명 (reference, tag, version)
    • 오늘, 어제, 데브코스 시작일
  • 수정 내역을 추적
  • 이전 상태로 되돌림

주변에 있는 버전 관리 시스템

버전 관리 시스템

그 중에서도 Git

Git을 잘 다룰 수 있으면 좋은 점?

  • 사용하는 기술 스택(언어 4번, 프레임워크 6번)이 변화하는 와중에도 변하지 않는 도구

Git 시작하기

Git Clients

Git 설정

git config --global user.email "<email>"
git config --global user.name "<name>"

git config --global --list
git config --global --edit

Git 저장소 만들기

git init [<directory>]
# or
git clone <repository> [<directory>]

git status

Commit

> '의미' 있는 변화​

  • 커밋은 언제 해야 할까요?
  • 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 HEAD

Repository 관리 전략

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

  • 167