핵심 정리

# Sourcetree가 특히 유용한 상황
- 변경된 파일 중 일부 줄(hunk)만 선택해서 커밋
- 브랜치 그래프로 merge·rebase 후 히스토리 검증
- 긴 히스토리에서 특정 파일 변경 이력 추적

기본 흐름

어떤 Sourcetree 흐름을 먼저 떠올리면 되나

줄 단위 stage 선택이 실무에서 자주 필요한 이유 — 논리적 단위와 파일 단위는 다르다

하나의 파일을 수정하다 보면 서로 관련 없는 변경이 섞이는 경우가 많다. 버그 수정과 리팩터링이 같은 파일에 들어간 상황이 대표적이다. CLI에서는 git add -p로 hunk 단위로 선택할 수 있지만 터미널 인터페이스가 불편하다. Sourcetree는 파일 diff를 보면서 체크박스로 줄 단위, 블록 단위 선택을 직관적으로 할 수 있어 커밋 단위를 논리적으로 분리하기 쉽다. 논리적으로 분리된 커밋은 나중에 git bisect나 revert 사용 시 훨씬 정확하게 동작하며, 코드 리뷰 과정에서 변경 의도를 더 명확하게 전달한다.

브랜치 그래프가 히스토리 검증에 유용한 이유 — Git 객체 그래프를 눈으로 봐야 확신이 생기는 상황이 있다

Git의 히스토리는 내부적으로 커밋 객체들이 부모를 가리키는 DAG(방향성 비순환 그래프)다. rebase나 merge 후 이 구조가 예상대로 정리됐는지, 또는 장기간 운영된 프로젝트에서 feature 브랜치가 언제 어디에서 병합됐는지 추적할 때 Sourcetree의 레인 기반 그래프가 유용하다. CLI git log --graph --oneline으로도 비슷한 정보를 볼 수 있지만 레인이 많아지면 읽기 어렵다. 다만 그래프는 판단을 돕는 도구일 뿐이며, 문제를 발견했다면 실제 수정은 정확한 Git 명령으로 처리하는 것이 안전하다.

GUI 클라이언트의 한계 — 버튼이 많을수록 의미를 모르고 누르기 쉽다

Sourcetree는 interactive rebase, stash, cherry-pick, submodule 같은 고급 Git 기능까지 버튼으로 접근할 수 있다. 이는 접근성을 높이지만 동시에 "어떤 Git 동작이 실행되는가"를 확인하지 않고 버튼을 누르기 쉽게 만든다. force push, reset --hard, 브랜치 삭제 같은 되돌리기 어려운 작업은 GUI에서도 CLI와 같은 수준의 주의가 필요하다. Sourcetree를 쓰더라도 수행하려는 작업의 Git 의미를 이해하고 진행하는 것이 전제이며, 이상한 동작이 보이면 git status와 git log로 실제 상태를 직접 확인해야 한다.

선택 기준

주의할 점