핵심 정리

# 파일 복사 방식의 문제
- report-final.docx
- report-final-real.docx
- report-final-real-2.docx
# → 어느 것이 최신인지, 무엇이 달라졌는지 알 수 없다

# Git 방식
- commit으로 변경 시점과 의도를 기록
- branch로 실험을 본선과 분리
- diff로 두 시점의 차이를 정확히 확인
- revert로 특정 변경만 안전하게 되돌리기

왜 쓰나

Git을 왜 쓰는지 먼저 무엇을 떠올리면 되나

Git은 스냅샷 기반으로 히스토리를 기록한다 — 단순 파일 복사와 근본적으로 다르다

파일을 복사해 버전을 관리하면 "어느 것이 최신인가", "두 버전 사이에 무엇이 달라졌는가"를 사람이 직접 파악해야 한다. Git은 git commit마다 작업 트리의 전체 스냅샷을 blob/tree 객체로 저장하고 커밋 객체가 이를 가리킨다. 이 체인을 따라가면 어느 시점에든 정확히 그때의 상태를 재현할 수 있다. Git이 저장하는 것은 파일의 변경 "차이"가 아니라 스냅샷이기 때문에, 특정 시점 전체를 꺼내는 속도가 빠르다.

브랜치로 실험을 분리하면 본선이 안전하다 — 되돌리기 비용이 낮다

브랜치는 특정 커밋을 가리키는 가벼운 포인터다. 새 브랜치를 만들어도 파일을 복사하지 않으므로 비용이 거의 없다. 실험적인 기능이나 버그 수정을 별도 브랜치에서 진행하면, 잘못됐을 때 브랜치를 삭제하거나 main으로 돌아오면 그만이다. 파일을 직접 수정했다가 복구해야 하는 상황과 비교하면 되돌리기 비용이 극적으로 낮다. 이 점이 "먼저 브랜치를 만들고 작업하라"는 Git 협업 문화의 배경이다.

분산 버전 관리라 clone 자체가 백업이다 — 중앙 서버 장애에도 히스토리가 살아있다

SVN 같은 중앙 집중식 버전 관리에서는 서버가 없으면 히스토리에 접근할 수 없다. Git은 분산 방식이라 각 개발자의 로컬 저장소가 전체 히스토리를 독립적으로 보유한다. 원격 저장소(GitHub, GitLab 등)가 다운되어도 로컬에서 커밋, 브랜치 생성, 히스토리 확인이 모두 가능하다. 여러 개발자가 clone을 갖고 있으면 그것 자체가 자연스러운 이중화다.

협업 기록이 남는다는 것은 책임 소재가 아니라 맥락을 보존하는 것이다

git blame이나 git log로 특정 코드가 언제 누가 어떤 이유로 작성했는지 확인할 수 있다. 이는 버그가 생겼을 때 비난하기 위한 도구가 아니라, "이 코드가 왜 이렇게 작성됐는가"라는 의사결정 맥락을 나중에 이해하기 위한 도구다. 좋은 커밋 메시지가 중요한 이유가 여기 있다. 코드 변경 자체보다 변경 이유를 메시지에 남기는 습관이 팀의 장기적 유지보수 비용을 낮춘다.

실무에서 볼 점

주의할 점