[Git] CLI vs GUI, Reset vs Revert, Merge vs Rebase

협업을 진행하는데 필수적인 Git에 대해서 개념과 목적을 처음부터 다시 잡기 위해 강의를 수강하고 있다.

강의를 들으면서 핵심 부분을 기억하기 위한 목적으로 포스팅을 하게 되었다.

 

📌 CLI vs GUI

Git을 사용하는 방법은 두 가지로 나뉜다.

• 터미널에 직접 명령어를 입력하여 수행하는 CLI방식
• 소스트리 등의 프로그램을 사용하는 GUI방식

CLI(Command Line Interface)

CLI는 Command Line Interfaced의 약자로 말 그대로 명령줄을 입력해서 사용하는 것

 

GUI(Graphical User Interface)

GUI는 Graphical User Interface의 약자로 일반인 사용자들이 쓰기 편하도록 그래픽 요소를 활용한 인터페이스

 

무엇을 사용해야 하는가?

Git에서 무엇인가를 실행하기 위한 명령들을 당장 내려야 할 때는 CLI를 사용하고 시각적으로 프로젝트의 상태를  Git상에서 자세히 살펴보아야 할 때는 GUI를 사용하는 것이 편리하다.

소스트리와 같은 GUI툴은 당장 사용하기 편하지만 Git의 모든 기능을 섬세하게 다룰 수 있도록 만들어지지 않았기 때문도 있고, CLI를 사용함으로써 Git에 대해 보다 정확히 이해하고 제대로 사용할 수 있기 때문이다.

 

---

📌 Reset vs Revert 

Git에서 과거 시점으로 돌아가기 위한 방법은 두 가지가 있다.

• reset : 원하는 시점으로 돌아간 뒤 이후 내역들을 삭제한다.
• revert : 되돌리기 원하는 시점의 커밋을 거꾸로 실행한다.

reset 

reset은 만약 이전의 커밋 시점으로 되돌리려면 이전 커밋시점으로 되돌아간 후 이후의 내역들은 히스토리에서 삭제한다.

revert

revert는 이전 커밋 시점으로 되돌아간 후 이후의 내역들을 삭제하는 것이 아니라 이전 커밋시점의 변경 내용을 거꾸로 수행하는 커밋을 생성함으로써 추가된 것이 있다면 삭제하고 변경한 것이 있다면 반대로 수행한다. 그래서 결과적으로 과거의 상태와 같은 상태로 돌아간다.

 

과거 커밋사항으로 되돌아간 것을 히스토리에 남겨야 할 필요가 있거나, 과거 커밋시점 이후의 내역들을 유지하되 과거 커밋의 내용만 취소해야 하는 경우 revert를 사용한다. 

개발자들은 Git을 사용해서 코드를 공유하고 협업하는데 한 번 공유공간에 올라간 내용을 reset 해버리면  그것을 기반으로 작업한 다른 사람들의 코드와 심각한 충돌을 일으키게 될 것이고 협업 시 문제가 발생할 것이다. 때문에 한 번 공유가 된 커밋들은 revert를 사용해서 되돌려야 한다.

 

---

📌 Merge vs Rebase

Branch를 합치는 방법은 두 가지가 있다.

• merge : 다른 브랜치의 변경 내역을 현재 브랜치로 변경 내용을 통합하는 데 사용한다. 브랜치의 사용 내역을 남길 필요가 있을 때 적합한 방식이다.
• rebase : 현재 브랜치의 변경 내역을 다른 브랜치로 옮기는 데 사용한다.  현재 브랜치의 커밋들을 다른 브랜치의 커밋내역 위로 재배치하기 때문에 한 줄로 깔끔히 정리된 내역을 유지하기 원할 때 적합하지만 이미 팀원과 공유된 커밋들에 대해서는 사용하지 않는 것이 좋다.

Merge

merge는 병합이라는 말 뜻처럼 브랜치를 한 커밋에 이어 붙이는 것으로, 이 과정에서 작업한 브랜치의 커밋 변화들을 병합하려는 브런치에 이어 붙이는 커밋 하나가 더 생겨난다. 즉, 작업한 브랜치의 커밋 변경 내용을 병합하려는 브랜치에 한 번에 적용하는 것으로 볼 수 있다.

 

Rebase

작업한 브랜치의 각각의 변경 사항을 병합하려는 브랜치로 옮겨 붙이는 것을 말한다. 

 

Merge와 Rebase 차이

Merge와 Rebase 차이는 히스토리의 내역이다. rebase를 한 뒤 히스토리는 깔끔하게 한 줄로 정리되지만 merge는 브랜치의 흔적을 남긴다. 브랜치가 몇 개 안 된다면 문제가 되지 않지만 많은 브랜치가 사용되는 프로젝트에서는 진행 내역을 보고 파악하기가 복잡해질 수 있다.

merge는 다른 브랜치들을 유지한 채 현재 브랜치로 변경사항을 병합하지만 rabase는 현재 브랜치의 각각의 변경사항을 다른 브랜치에  옮겨 붙이는 것이기 때문에 히스토리를 깔끔하게 한 줄로 유지할 수 있다.

진행하는 프로젝트의 성격에 따라 브랜치의 히스토리를 남겨둘 필요가 있다면 merge를, 그보다는 히스토리를 깔끔하게 유지해야 한다면 rebase가 더 적절한 선택이 될 것이다. 하지만 rebase는 변경 내역을 이어 붙이는 것인 만큼 팀원들 간에 공유된 커밋들에 대해서 충돌 가능성이 있기 때문에 사용하지 않는 것이 좋다.