GitHub Desktop은 Git을 처음 사용할 때 굉장히 편리한 도구이다. Commit, Push, Pull 같은 기본적인 작업을 간단하게 처리할 수 있어 Git을 깊게 이해하지 않아도 협업이 가능하다.
나도 오랫동안 GitHub Desktop을 사용했는데, 프로젝트의 규모가 커지고 브랜치가 많아질 수록 GitHub Desktop의 한계를 느낄 수밖에 없었다.
그래서 이번 글에서는 GitHub Desktop을 사용하다 Fork로 옮기게 된 이유와, 두 도구가 Git을 다루는 관점에서 어떤 차이를 가지는지, 그리고 Fork를 어떻게 사용하는지 정리해보려고 한다.
[1. GitHub Desktop의 한계는 언제 드러날까?]
GitHub Desktop은 "문제 없이 흘러갈 때" 가장 빛나는 도구이다.
하지만 다음과 같은 상황이 반복되기 시작하면, 이야기가 달라진다.
- 브랜치를 여러 개로 나누어 작업할 때
- main과 feature 브랜치의 차이를 정확히 파악해야 할 때
- 커밋을 되돌리거나 히스토리를 정리해야 할 때
여기서 GitHub Desktop은
무엇이 어떻게 바뀌었는지를 설명해주지 않는다.
- 지금 HEAD가 어디를 가리키는지
- 이 커밋이 어느 브랜치에 포함되는지
- merge인지 rebase인지
대부분의 작업이 버튼 하나로 간편하게 처리되지만,
그만큼 Git 내부에서 어떤 일이 일어나는지는 알기 어려워진다.
[2. Fork 첫 인상]
Fork를 처음 실행했을 때 가장 인상 깊었던 점은
커밋 히스토리가 그래프 형태로 그대로 드러난다는 것이었다.
- 브랜치가 어디서 갈라졌는지
- 어떤 커밋이 어떤 브랜치에 포함되는지
- 현재 체크아웃된 브랜치가 어디를 가리키는지
GitHub Desktop에서는 알 수 없었던 정보들이
Fork에서는 한 화면에 구조적으로 표현된다.
이 부분에서 Fork는
"Git을 쉽게 쓰게 해주는 도구"라기보다는
"Git의 동작을 숨기지 않는 도구"라는 인상을 받았다.
[3. Fork의 기본 화면 구성]
Fork의 기본 화면은 크게 세 영역으로 나뉜다.
좌측 영역은 현재 저장소의 상태를 보여주는 영역으로, Working Copy, 브랜치, 원격 저장소 목록 등을 확인할 수 있다.
중앙 영역은 Commit Graph로, 브랜치와 커밋 히스토리의 흐름을 시각적으로 확인할 수 있다.
하단 영역은 선택한 커밋이나 파일의 상세 정보를 보여주며, Commit 정보, Diff, 파일 구조 등을 상황에 따라 확인할 수 있다.
[4. 변경사항 확인과 Commit]
당연히 GitHub Desktop과 마찬가지로 Fork에서도 변경된 파일을 확인하고 Commit을 생성할 수 있다.
하지만 Fork에서는 한 단계 더 세밀한 제어가 가능하다.
- 파일 단위 Stage / Unstage
- Diff에서 특정 줄만 Stage
- Commit 메시지 수정 (Amend)
Commit은 단순한 저장이 아니라, 히스토리를 만드는 행위이며, Fork는 이 과정을 숨기지 않는다.
[5. 브랜치를 다루는 방식의 차이]
Fork에서 브랜치는
"작업 공간"이 아니라 "커밋을 가리키는 포인터" 라는 점이 명확하게 드러난다.
- main이 가리키는 커밋
- feature 브랜치가 가리키는 커밋
- 두 브랜치가 어디서 갈라졌는지
이 구조가 시각적으로 드러나기 때문에
다음과 같은 질문에 바로 답할 수 있다.
- 왜 main에는 변경사항이 없는가?
- 이 커밋은 어느 브랜치에서 만들어졌는가?
[6. Fork에서 가능한 히스토리 조작]
Fork는 Git이 제공하는 히스토리 관련 기능을 거의 그대로 UI로 노출한다.
- Reset (soft / mixed / hard)
- Revert
- Rebase
- Cherry-pick
처음에는 다소 부담스럽게 느껴질 수 있지만,
이 기능들은 원래 Git이 가지고 있는 기능이다.
Fork에서는 이러한 기능들을 모두 사용할 수 있기 때문에,
각 기능의 의미를 이해한 뒤 필요한 경우에 사용하는 것이 중요하다.
[6.1 Reset : 커밋을 어디까지 되돌릴 것인가?]
Reset은 현재 브랜치가 가리키는 커밋을 과거의 특정 시점으로 되돌리는 기능이다.
Fork에서는 Reset을 세 가지로 명확히 구분해서 보여준다.
- Soft Reset
- 커밋만 되돌림
- 변경 사항은 Stage 상태로 유지
- Mixed Reset
- 커밋만 되돌림
- 변경 사항은 Unstaged 상태로 유지
- Hard Reset
- 커밋 + 변경 사항 모두 제거
Reset은 히스토리를 직접 수정하는 작업이기 때문에,
언제 어떤 범위까지 되돌릴지 명확히 알고 사용해야 한다.
GitHub Desktop에서는 이런 기능이 UI로 거의 드러나지 않지만,
Fork에서는 히스토리를 어떻게 바꾸는지 명확하게 보여준다.
[6.2 Revert : 되돌리되, 기록은 남긴다]
Revert는 특정 커밋의 변경 사항을 취소하는 새로운 커밋을 추가하는 방식이다.
- 기존 히스토리는 유지
- "이 커밋을 되돌렸다"라는 기록이 남음
- 협업 중인 브랜치에서 안전하게 사용 가능
Reset이 "과거를 수정하는 방식"이라면,
Revert는 "과거를 인정한 채 되돌리는 방식"이다.
Fork에서는 커밋을 우클릭하는 것만으로
Reset과 Revert를 명확히 구분해서 사용할 수 있다.
[6.3 Rebase : 커밋을 다시 정렬한다]
Rebase는 커밋의 기준점을 옮겨 히스토리를 다시 정렬하는 작업이다.
주로 다음과 같은 상황에서 사용된다.
- feature 브랜치를 최신 main 위로 올릴 때
- 커밋 흐름을 직선적으로 정리하고 싶을 때
Rebase를 사용하면 히스토리가 깔끔해지지만,
기존 커밋이 새로운 커밋으로 다시 생성되며 SHA가 변경된다.
따라서 Rebase는 히스토리를 '정리'하는 도구지, 무조건 사용해야 하는 기능은 아니다.
[6.4 Cherry-pick : 필요한 커밋만 가져오기]
Cherry-pick은 특정 커밋 하나만 골라
현재 브랜치에 적용하는 기능이다.
예를 들어 다음과 같은 상황에서 사용할 수 있다.
- 다른 브랜치의 버그 수정 커밋만 가져오고 싶을 때
- 전체 merge 없이 일부 변경만 필요할 때
Cherry-pick은 브랜치 단위가 아니라,
커밋 단위로 작업할 수 있게 해준다.
Fork에서는 커밋을 우클릭해 바로 Cherry-pick을 수행할 수 있고, 적용 결과도 즉시 확인할 수 있다.
[7. 마무리]
GitHub Desktop은 Git을 처음 접하거나, 단순한 작업 위주라면 충분히 좋은 도구이다.
하지만 프로젝트 규모가 커지고 브랜치와 히스토리를 직접 관리해야 하는 순간부터는 Fork 쪽이 훨씬 유용하다고 생각한다.
이번 글을 시작으로, 앞으로는 Fork를 본격적으로 사용하며 Git의 동작을 도구에 맡기기보다는, 커밋과 브랜치, 히스토리가 실제로 어떻게 구성되고 변경되는지를 직접 이해하는 방향으로 학습을 이어가려고 한다.
이를 통해 단순히 작업을 처리하는 수준을 넘어, Git을 보다 안정적이고 예측 가능하게 사용할 수 있는 기반을 만들어보려고 한다.
