Reset : 특정 과거 시점으로 돌아가기
Revert : 특정 과거 시점으로 돌아가기
그렇다면 두가지의 차이는 ?
1. Reset
헤드와 브랜치 모두 특정 과거 시점을 가리키게 된다.
리셋에는 세가지 옵션 (과거로 돌아가는 3가지 방법)이 있다.--soft
- repo 값만 변경됨, 나의 레포 최신 커밋은 과거 시점을 가리키고, staging은 가장 최근 커밋 그대로
- 보통 Staging Area에 올린 것을 수정하고 싶을 때 soft를 통해 unstaging 하여 수정하여 다시 commit하는 작업에 많이 사용된다.
--mixed
- 다섯번째 커밋 단계에서 mixed reset할 경우 작업중이던 디렉토리는 다섯번째 그대로, 스테이징은 3번째로 돌아감
--hard
- Local Repository , Staging Area, Working Directory 모두 과거 시점으로
디폴트는 mixed
- git reset(commit id) -> default 가 --mixed이다.
- 주니어 대부분 git reset--hard(commit id)를 씀
- 하지만 실무에서는 hard를 잘 쓰지 않는다 (내가 쓴 코드가 날라가는 것이기 때문에)
- 심각한 경우 (꼬인 것을 풀지 못할 경우) hard를 쓴다.
✔️ git reflog
- git은 추가를 통해 삭제를 표현한다. 따라서 어딘가에 리셋 전의 커밋이 살아있다.
- git reflog를 통해 이러한 깃과 헤더의 모든 변경값을 확인할 수 있음
- git reflog를 통해 커밋 아이디를 알아낸 다음 git reset을 통해 해당 시점으로 돌아갈 수 있다.
✔️ 무한반복
- local repo에서 다섯개의 커밋을 remote로 Push
- 세번째 커밋으로 되돌리고 싶어서 local repo에서 git reset을 통해 되돌렸다.
- remote에도 적용하기 위해 Push
- 에러가 뜬다 (remote에 최신 코드가 있으니 pull 받아라!)
- 원하지 않지만 pull
- 다시 2번부터 시작
-> 이러한 반복을 막기 위해선 강제 push를 해야한다. 하지만 강제push는 협업에서 지양
(다른 팀원들은 다섯개의 커밋을 바탕으로 브랜치를 따서 이미 작업하고 있을 수 있기 때문에)
2. Revert
변경 커밋을 남기며 특정 과거 시점으로 돌아가는 방법
- 과거 커밋시점으로 돌아갈 때, 변경 이력을 남기며 돌아감
- 코드의 시점은 과거로 변하지만, 커밋은 미래시점으로 변경
- Remote repository push 가능
- 협업시 Reset이 아닌, Revert 사용 권장
- Revert도 잘못 사용하면, 충돌날 수 있음
- 과거시점의 특정 커밋만 Revert 가능 (권장 x)
