코드를 잃고 시작한 Git 공부

Git을 쓰면서도 한동안 기본 브랜치에만 작업하고 커밋 기록은 거의 관리하지 않았습니다. 어느 주에 코드를 여러 번 잃고 나서야 “명령어 몇 개를 외우는 것”이 아니라 변경을 안전하게 남기는 방식을 배워야겠다고 마음먹었어요.

버전 관리는 무엇을 지키는가

버전 관리는 파일의 변화를 시간에 따라 기록하고, 필요할 때 특정 시점으로 돌아갈 수 있게 합니다. 소스 코드뿐 아니라 문서와 이미지도 관리할 수 있어요.

방식	저장 위치	협업과 복구 관점
폴더 복사	개인 컴퓨터의 여러 사본	간단하지만 이름과 복사 실수에 취약함
로컬 VCS	개인 컴퓨터의 변경 이력	변경을 체계적으로 되돌릴 수 있지만 공유가 어려움
중앙 집중식 VCS	하나의 중앙 서버	구성원이 같은 이력을 보지만 서버 장애에 의존함
분산 VCS	각 사용자의 전체 저장소와 원격	로컬에서도 이력을 보존하고 여러 원격과 협업 가능

Git은 분산 버전 관리 방식입니다. 이 구조를 이해하고 나니 커밋은 단순한 저장 버튼이 아니라, 나중에 변경의 목적을 찾고 되돌릴 수 있게 만드는 기록 단위로 보였습니다.

커밋 메시지에는 무엇과 왜를 남긴다

2016년에 커밋 메시지 작성법을 읽고 가장 크게 남은 원칙은 “어떻게”보다 “무엇을 왜 바꿨는지” 적는 것이었습니다. 구현 방법은 diff에서 확인할 수 있지만, 그 선택의 배경은 메시지에 남기지 않으면 사라지기 쉬워요.

실제로 적용하기 좋은 기준은 다음과 같습니다.

• 제목과 본문 사이에 빈 줄을 둔다.
• 제목은 한눈에 읽을 수 있게 짧게 쓴다.
• 한 커밋에는 하나의 설명 가능한 목적을 담는다.
• 본문에는 변경의 배경, 제약, 선택하지 않은 대안을 남긴다.
• 팀이 정한 언어와 형식을 일관되게 따른다.

명령줄과 GUI 중 무엇이 더 올바른지는 핵심이 아니었습니다. 명령이 실제로 어떤 이력을 만드는지 이해하고 있다면, 내용을 읽기 쉽게 보여주는 도구를 선택하는 편이 생산적입니다.

브랜치와 pull request를 처음 다뤘을 때

처음 pull request를 올리려 할 때는 커밋을 정리하고, 원격에 올리고, 자동 검사를 기다리는 단계가 생각보다 많게 느껴졌습니다. 하지만 흐름을 나누면 각 단계의 책임이 분명해집니다.

1. 작업 브랜치에서 작은 목적 단위로 커밋합니다.
2. 변경 내용을 스스로 읽고 불필요한 파일을 제거합니다.
3. 원격 브랜치에 올리고 pull request에서 배경과 검증 결과를 설명합니다.
4. 자동 검사와 리뷰 의견을 반영합니다.
5. 합쳐진 뒤에는 배포나 후속 작업이 정상인지 확인합니다.

브랜치는 작업을 격리하고, pull request는 변경을 검토 가능한 대화로 바꿔줍니다. CI는 그 대화에 반복 가능한 검증을 보탭니다.

대화형 rebase는 언제 쓰나

git rebase -i HEAD~N은 최근 N개 커밋을 다시 정리할 때 사용할 수 있습니다. 대표적으로 pick은 그대로 두기, reword는 메시지 수정, squash는 앞 커밋과 합치기를 뜻합니다.

다만 이미 다른 사람이 바탕으로 작업한 공개 이력은 함부로 다시 쓰면 안 됩니다. 대화형 rebase는 원격에 공유하기 전 자신의 작업 브랜치를 읽기 좋게 다듬는 용도로 제한하는 것이 안전합니다.

결국 지키려던 것

처음 목표는 코드를 다시 잃지 않는 것이었습니다. 공부를 이어가며 목표가 조금 넓어졌어요. 변경을 복구할 수 있고, 동료가 이유를 이해할 수 있고, 미래의 내가 다시 봐도 다음 행동을 판단할 수 있는 이력을 만드는 것. Git을 잘 쓴다는 건 많은 명령어보다 이 세 가지를 꾸준히 지키는 일에 가깝습니다.

이어 읽기

• 2016년의 작은 기록들 — Git을 본격적으로 공부하기 전후의 초기 개발 기록을 함께 볼 수 있어요.
• 프론트엔드 멘토링 진행 노트 — Git의 기본 흐름을 입문자에게 설명하고 실습으로 연결한 방식입니다.
• 개발자로 성장하며 남긴 질문들 — 커밋과 프로젝트 기록을 포트폴리오와 이직 준비에 어떻게 활용했는지 이어집니다.