Git 컨셉과 명령어 동작
Git이란?
버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템
저장소(서버) 위치
로컬 버전 관리: RCS, 변경되는 부분만을 관리
중앙집중식 버전 관리: 개인별 Snapshot, 별도의 중앙 서버(ex. CVS, Subversion)
분산식 버전 관리: 전체 정보 저장, Cloud 사용(Github) (ex. Git)
저장 방식
델타 기반 관리: 파일의 변경 데이터를 관리 (이미지 참조)

스냅샷의 스트림처럼 관리: 시간순으로 프로젝트의 스냅샷을 저장 (이미지 참조)

GIt 구성요소
3가지 상태로 구성되어있다.
Committed: 로컬에 저장된 상태
Modified: 수정하였지만 로컬 데이터에 저장하지 않은 상태
Staged: 수정한 파일을 커밋할 것이라 표시한 상태
Git의 단계
3가지 단계가 있고 위의 상태와 1:1 매핑된다.
Git Directory(Repository) = Committed
Git을 clone하거나 init할 때 만들어진다
Working Tree = Modified
특정 버전을 checkout(Git Directory안의 파일)
Staging Area = Staged
index라고도 하며 커밋할 내용을 표시한 파일
Git 명령어별 동작
git init: .git이라는 디렉토리를 만든다.
// .git 내부구조
config
description
HEAD -> 현재 checkout한 브랜치
hooks/
info/
objects/ -> 모든 컨텐츠를 저장
refs/ -> 커밋 개체의 포인터(브랜치, 태그, 리모트) 저장
index -> staging area의 정보를 저장git reset

가리키는 커밋(HEAD)를 되돌린다. (reset --soft는 여기까지)
Index를 현재 커밋이 가리키는 스냅샷으로 업데이트 (reset --mixed는 여기까지, reset의 기본 옵션)
Working Directory를 index 상태로 업데이트(reset --hard는 여기까지)
checkout는 reset --hard + Working Directory의 안전을 보장
git rebase
Merge는 두 브랜치의 마지막 커밋 2개와 공통 조상의 커밋으로 3-way merge를 하는 것이 일반적이다.

Rebase는 공통 커밋(조상)으로 이동하고 지금까지의 커밋을 임시로 저장해둔 다음 Rebase할 브랜치에 차례대로 저장하여 선형을 만든다.

Git 명령어 사용 사례
커밋 메세지 수정
커밋 자체가 수정되면서 추가로 수정사항을 밀어넣게 되며 해시값이 바뀐다.
git commit --amendMerge 리셋
로컬은 커밋을 옮기는 방법을 사용한다
git reset --hard HEAD~원격은 커밋을 되돌린다.
git revert -m 1 HEADAdd/Commit/Push 취소
Add 취소
Staging -> UnStaging
git reset HEADCommit 취소
마지막 커밋을 취소(로컬)
git reset HEAD^Push 취소
기록을 남기기 위해서는
revert(권장)강제로 덮어쓰기는
reset
Reference
Last updated