Commit

git의 3가지 상태

• modified
• staged
• committed

git의 3가지 저장 공간

• working directory (modified)
• staging area (staged)
• git repository (committed -> push)

checkout : 어떠한 상태로 되돌리겠다, 불러오겠다

gitignore

버전 관리에서 제외

gitignore 파일을 자동으로 생성해주는 사이트 (https://www.toptal.com/developers/gitignore)가 있음

브랜치

Branch

가상의 작업 공간

master(main), hotfix, release, develop, feature 등..

브랜치는 커밋을 가리키는 포인터

Merge

한 브랜치의 내용을 다른 브랜치에 합치는 것

변경 사항이 있는 브랜치로 먼저 체크아웃 해야함

testing 브랜치에서 Merge into 'main'...

fast-forward

testing2 브랜치 생성

서로 다른 작업을 한 것이 아닌 testing2에서만 작업 진행

이후 merge시, main이 testing2를 따라가기만 하면 merge되는 효과

즉, base 브랜치에는 변경사항이 없고, 파생된 브랜치에만 변경이 있을 때

git-flow

브랜치 관리 모델 중 하나로 Vincent Driessen이 주장

아래 두 브랜치는 항상 존재하는 메인 브랜치

• master(main) : 배포된 소스가 있음
• develop : 다음 배포를 위한 소스가 있음, 개발이 완료되면 일련의 과정을 통해 master(main)로 머지

서포팅 브랜치 : 팀 멤버들이 병렬로 일할 수 있도록 도와주는 브랜치

• feature
• release
• hotfix

feature 브랜치

• 생성 : develop으로부터
• 머지 : develop으로
• prefix : feature/
• develop으로부터 분기, 특정 기능 하나에 대해 개발 후 다시 develop 브랜치로 머지
• fast-forward를 사용하지 않는다 (git merge --no-ff)

release 브랜치

• 생성 : develop으로부터
• 머지 : develop, master로
• prefix : release/
• release 브랜치를 따로 가져가기 떄문에 나머지 사람들은 develop에서 계속 개발할 수 있음
• 작은 버그, 메타 데이터(버전) 관리

hotfix 브랜치

• 생성 : master로부터
• 머지 : develop, master로
• prefix : hotfix/
• master 브랜치로부터 긴급 수정 사항들을 수정 후 바로 반영

Remote

로컬 브랜치 / 원격 브랜치가

• 로컬 브랜치인 main과 원격 브랜치인 origin/main은 다른 저장소
• git이 origin/main을 체크아웃하여 로컬 브랜치인 main을 생성

Fetch

원격 저장소의 변경 사항을 내려 받는 것

로컬의 내 main은 그대로, origin/main만 서버의 main을 쳐다봄

Pull

fetch + 머지

origin/main을 로컬의 내 main에 머지해주는 것

Push

로컬 저장소의 변경 사항을 원격 저장소로 올리는 것