---
# System prepended metadata

title: git 정리
tags: [git]

---

---
tags: git
---
git 정리
===

## 상태
### HEAD
현재 체크아웃이 지정한 커밋시점을 가리킴.
dev로 체크아웃 했더라도 특정 커밋시점으로 이동하면 그것이 바로 HEAD


### working directory (==working copy)
작업공간. 
새로 추가된 관리되지않는 파일, 변경된 사항이 있는 파일, 삭제된 파일 등 깃이 관리해야할 디렉토리의 모든 파일들

### index (== stage arege)
커밋하기 전에 잠시 담아두는 공간




## reset (초기화)
커밋을 초기화 한다. 그중 hard, mixed 두가지가 있다.
- hard : 커밋도 초기화하고 작업을 모두 지운다.
- **mixed** : 커밋을 지우고, index(stage) 에서도 지운다. 다만 변경사항은 워킹디렉토리에 남겨준다.
- soft : mixed 와 달리 index(stage) 에는 남겨준다.

hard는 강력하고 위험하니 주의해서 사용하자. soft는 그닥 효용성은 못느끼겠다. stage에 남겨서 뭐 하겠다고.
**mixed 를 가장 자주 쓰게 될듯하다.**

## revert (되돌리기)
revers commit 이라고도 한다. 말그대로 특정 커밋을 취소하기 위해 삭제이력을 남기면서 커밋해준다. 
예를들어 `(+)'1줄추가'`라는 내용을 추가한 커밋이력이 있고 그 커밋을 revert 한다면, `(-)'1줄추가'` 를 기록으로 남기면서 커밋해준다.
> 작업내역 역으로 순차적으로 해야한다. 현재 (HEAD) 의 바로 아래만 시도해야 한다는 뜻.
> 안그러면 컨플릭트가 난다.

**revert.. 존재 이유는 알겠는데 이력이 지저분해 질듯 하다. 다른사람의 커밋을 되돌리고자 할때 이력을 굳이 남기고 싶다면 쓰겠지만, 이경우 그냥 커밋한 사람에게 이관할듯 싶다.**

## merge (병합)
다들 아시죠? 패스

### merge 시 충돌 최소화 하기
현재 작업중인 `지금브랜치`가 언젠가 `master` 로 해야하는 브랜치라면 (merge into master),
master 의 변경을 받아오는게 현명하다 (merge into `지금브랜치`)

> 물론 이때도 충돌이 날수 있다. 하지만 충돌의 크기가 작기 때문에 해결하기가 쉽다.


## rebase (re-base)
병합의 개념이지만 메커니즘이 다르다.
가지쳐서 나온 브랜치의 base 까지 커밋이력을 다른 브랜치에 새로이 커밋한다.
때문에 fast-forward 해주기 위해 merge into master 까지 해줘야 한다.

merge와 달리 가지가 1개만 관리되므로 커밋이력이 정돈된다는 장점이 있다.

### rebase -interaction
특정 커밋을 이전의 커밋과 합치기 위해 squash 할수 있다.
다른 기능도 있는데 주로 squash 용도.