Git Commit을 취소하는 방법 Revert, Reset, Rebase, Amend

http://git-scm.com/docs/git-reset

Git - git-reset Documentation

https://git-scm.com/docs/git-revert

Git - git-revert Documentation

https://git-scm.com/docs/git-rebase

Git - git-rebase Documentation

 

Git을 사용하다가 문제가 발생하면 일단 이곳들을 참조해서 먼저 해결해본다.

https://backlog.com/git-tutorial/kr/stepup/stepup2_7.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%90%98%EB%8F%8C%EB%A6%AC%EA%B8%B0

Git - 되돌리기

 

이렇게 해결이 되었다면 아무 문제가 없겠지만, 해결이 안되었다면 다음의 선택지 중에서 하나를 선택해서 문제를 해결해야 한다.

 

1. Revert 리버트

https://www.w3schools.com/git/git_revert.asp?remote=github 

Git Revert

Revert는 한국어로 '복귀', '되돌아간다'는 의미이다.

Git에서 Revert 명령어는 이전의 커밋을 선택하여 새 커밋으로 추가하는 명령어이다.

이때, log를 그대로 가지고있다.

 

 

2. Reset 리셋

https://www.w3schools.com/git/git_reset.asp?remote=github 

Git Reset

Reset은 눈물을 머금고 지금까지의 커밋을 포기하는 명령어이다. 

이전의 commit으로 돌아가서 그 이후의 변경 사항을 모두 포기한다는 의미이다.

지금까지의 커밋을 가지고 가야한다면 Reset 대신 Revert를 사용해야 한다.

 

리셋을 하기 전에는 현재 상태의 파일을 따로 압축을 하던 복사해서 붙여넣든 보관을 해야할 것 같다. 커밋을 상태를 뒤로 돌리면 돌이킬 수 없기 때문이다.

 

그리고 매우 중요한 주의점은 Reset은 나의 local repository 커밋에 대해서만 사용해야한다는 것이다. 

 

- 이클립스에서 리셋 사용법

이클립스에서는 history 탭을 활성화 시켜 놓지 않았다면 메뉴 Window - Shiw view - others... 들어가서 history 를 검색해서 나오는 것을 클릭하고 오픈하면 된다. 이클립스 버전에 따라 위치가 다르지만, 최신버전은 version control(team)이라는 메뉴 밑에 있다. 

그러면 앞서 작업하고 병합된 이력들이 나오는데 돌아갈 지점을 선택하고 우클릭 후 reset 메뉴에서 선택하면 된다.

 

- VS코드에서 리셋 사용법

 

소스관리 - branches 들어가서 해당 브랜치 클릭하면 이력이 아래에 쭉 뜨는데 거기서 돌아갈 커밋 선택 후 우클릭

이력 클릭하고 reset current branch to commit 클릭

 

3. Rebase 리베이스

 

(작성중)

 

4. Amend 어멘드

https://www.w3schools.com/git/git_amend.asp?remote=github 

Git Amend

가장 최근의 커밋 파일, 메시지를 수정하는 명령어이다.

수정한 파일을 추가할 때도 사용되지만, 개인적으로는 커밋 메시지를 수정하기 위해 많이 사용했다.

커밋 메시지를 규격화해서 사용하는 곳들이 많이 있는데, 그런 경우 PUSH시에는 reject가 나지만, 로컬 리파지터리에는 커밋이 되어 있어 push하려면 메시지를 수정해야하는데, 이럴때 amend를 많이 사용했다. 

이클립스에서 amend 명령어 사용은 매우 간단하다.

가장 최근 수정한 파일을 켜두고 Git 탭으로 간다.

Git탭의 commit message 영역에 있는 버튼 중 가장 좌측 버튼이 amend 버튼이다.

해당 버튼을 누르면 마지막 커밋 메시지가 자동으로 세팅되는데 이 메시지를 수정하고 다시 커밋하거나 푸쉬하면 된다.

혹시나 싶어 말하자면 이미 원격지의 공용으로 사용하는 브랜치에 머지를 하고 나서는 내 로컬 브랜치에서 수정을 했던 말았던 병합이 정상적으로 될 수가 없다. 

 

일단 이러한 문제를 막기 위해

 

1. 브랜치 사용하기

 

한 개 브랜치로 마치 SVN 사용하듯 사용하는 사람들도 있는데, 이러다가 이 페이지까지 흘러 들어온 사람이 많을 것이다. 작업할 때 브랜치를 따서 작업하고, 작업이 완료되면 머지하는 방식으로 작업하기를 추천한다. 

 

2. 상시적으로 소스 정렬하기

 

팀원간 합의하여 린트 툴을 동일하게 사용해서 항상 자동 정렬시켜 놓고, 작업 후에도 정렬을 해두어야 풀 리퀘스트(머지 리퀘스트) 전에 변경사항을 확인하기도 좋고, 코드 리뷰도 용이하다. 변경사항의 문제 사항, 누락 사항을 방지 하기 위해서는 이런 소소한 규칙을 잘 따르는 것이 좋다.

 

3. 각 팀원의 파일을 가능한 분리하기

 

사실 정렬을 잘 해놓으면 아무리 긴 파일이라도 변경 사항을 추적하기는 용이하다. 하지만 일단 한 파일을 공통으로 수정하는 것은 

 

-- 2023.01.02 작성중

 

예를 들어서, Spring 프레임워크로 웹 어플리케이션을 만들다고 하면 컨트롤러, 서비스 등을 분리하는 방식으로 작업하는 소스 파일을 분리시켜 가능하면 서로 공통으로 수정하는 상황을 만들지 않는 것이 좋은 것 같다. 한 화면의 코드를 몇 천 줄로 작성하고 그 파일을 공통으로 작업한다고 가정해보면, 

. 그리고 공통으로 작업하는 소스 파일은 항상 정렬을 해놓는다.

 

3. push 전에는 스스로 코드 한번 검수하기

 

내 개인 local repository는 commit history가 조금 엉킨다 해도 어떤 방법을 써서든 돌릴 방법이 있고, Git을 교육 받은 대로 정상적으로 사용하고 주기적으로 pull하고 commit하면서 작업해 왔다면 사실 크게 문제가 될 부분은 없다.

 

하지만 push를 통해서 원격지에 내 commit history를 넘겼고, 이를 pull, merge 했다면 이제는 history를 돌릴 생각은 접고, 새롭게 파일을 덮어써서 comitt, push, pull, merge 순으로 작업해서 해결하기를 추천한다. 원격지에서 undo를 하게 되면 해당 리파지터리를 사용하는 모든 사용자가 영향을 받기 때문이다.

 

4. 다른 Git 툴을 사용해 보기

 

이클립스는 Git이나 SVN 사용중 종종 sync 중 conflict 상황에 스테이징된 내용과 대상 파일이 동일함에도 같은 내용임을 인지 못하는 문제가 있는 것 같다. 요즘에는 그런 경우가 많이 줄어 들었지만, 특히 구버전일 수록 더 빈번한 것 같다. 이럴때, 만약 작업 분을 따로 가지고 있는 상태로 바로 hard reset하는 게 conflict 해결하는 것 보다 더 빠를 때도 있다.

작업하다가 뭔가 좀 이상하다 싶으면 다른 Git 툴을 사용해 보는 것도 방법이라 생각한다. Git 툴을 사용하면 명령어를 직접 타이핑 하지 않으니까 편하고, 빨리 처리할 수 있다는 장점이 있다. 하지만, 종종 이해할 수 없는 에러들이 나곤 하는데, 이럴 때 다른 Git 툴을 사용하면 정상 동작하는 경우가 꽤 있었다.

개발자들이 보통 사용하는 툴은 Eclipse 내의 Git 툴인 Eclipse EGit, VS Code의 기본 Git 이나 Git Lens 같은 것일 텐데, Source Tree나 GitHub Desktop 같은 툴로 다시 한번 작업해 보면 정상적으로 동작하는 경우가 있다.

 

5. Conflict 해결때는 좀 더 신경쓰기

 

같은 파일을 두명이 고쳤지만 서로 같은 부분을 건드리지 않았다면 충돌이 나지 않고 바로 Merge가 되지만, 같은 부분을 건드린 것으로 판단되면 결국 사람이 직접 충돌 상황을 해결해야한다. 다른 사람이 작업한 내용과 내가 작업한 내용을 정확하게 보고 충돌상태를 해결하자. 보통은 충돌 해결 문제때문에 개발자들끼리 싸움이 난다...

 

Git을 잘 쓴다는 건 명령어를 빨리 타이핑하거나 문제 상황을 빨리 해결하는 것을 말하는 것이기도 하겠지만, 내가 생각할 때는 가장 잘 쓰는 것은 팀원 모두가 원칙대로 사용하는 것이라고 생각한다.