Quick Reference
파일·hunk를 stage한 범위만 로컬 커밋에 들어가며, fetch는 파일을 바꾸지 않고 pull은 현재 브랜치에 통합해 충돌을 만들 수 있습니다.
| 하려는 일 | Sourcetree에서 확인할 곳 | Git 상태 |
|---|---|---|
| 수정 파일 살피기 | Working Copy의 파일 목록과 diff | 작업 트리에 아직 커밋하지 않은 변경이 있습니다. |
| 이번 커밋만 고르기 | 파일 또는 hunk를 stage | 선택한 변경이 index에 들어갑니다. |
| 로컬 기록 남기기 | 메시지 입력 후 commit | 현재 로컬 브랜치에 새 커밋이 생깁니다. |
| 원격 변경 확인 | fetch 후 원격 추적 브랜치 | 작업 파일은 바뀌지 않고 원격 정보만 갱신됩니다. |
| 원격과 통합 | pull 또는 merge/rebase | 현재 브랜치와 작업 트리가 바뀌며 충돌이 날 수 있습니다. |
| 병합 결과 읽기 | Log/History의 브랜치 라벨과 부모 관계 | 어느 커밋이 어디에 들어갔는지 확인합니다. |
변경을 작은 커밋으로 만들기
Sourcetree에서 stage한 범위만 다음 커밋에 들어갑니다. 한 파일에 버그 수정과 형식 변경이 함께 있다면 hunk 단위로 먼저 버그 수정만 stage하고, stage된 diff를 다시 읽은 뒤 커밋합니다. 커밋 단위가 분리되어 있으면 리뷰, revert, bisect 모두에서 변경 의도를 추적하기 쉽습니다.
git diff # 아직 stage하지 않은 변경
git diff --staged # Sourcetree에서 고른 다음 커밋 내용
git commit -m "Fix null session handling"파일 전체를 stage한 뒤 커밋 메시지로 의미를 보정하려 하지 마세요. 커밋 메시지는 변경을 설명하지만, 관련 없는 변경을 독립된 작업으로 바꾸지는 못합니다.
브랜치와 원격을 읽기
그래프에서 브랜치 이름은 특정 커밋을 가리키는 라벨입니다. 라벨 위치를 보고 현재 브랜치, 원격 추적 브랜치, merge가 발생한 지점을 확인할 수 있습니다. 다만 fetch한 정보가 오래됐다면 그래프의 원격 라벨도 오래된 것이므로, 협업 중인 브랜치라면 먼저 fetch합니다.
Pull은 단순 새로고침이 아닙니다. 원격 변경을 받아 현재 브랜치에 merge하거나 rebase하는 통합 동작이므로 충돌이 나면 파일을 고치고 stage한 다음 통합을 완료해야 합니다. pull 방식은 저장소 설정과 팀 규칙에 따라 달라질 수 있으므로, 버튼을 누르기 전에 어떤 방식으로 통합될지 확인합니다.
주의할 점
Sourcetree의 reset, rebase, force push도 명령줄의 같은 Git 동작입니다. 화면에서 쉽게 선택할 수 있다는 이유로 안전해지지 않습니다. 공유 브랜치에서 히스토리를 다시 쓰거나 원격을 덮기 전에는 git status, 현재 브랜치, 원격과의 차이를 반드시 확인하세요.
참고 링크
3 sources