Git · 협업 · 약 3분
날짜별 파일 복사 대신 Git으로 작업 기록 남기기
HTML·CSS 백업 경험을 출발점으로 작업 폴더, 스테이징, 커밋과 원격 백업의 차이를 익힙니다.
Wolfgadeok · 업데이트
파일명에 날짜를 붙이던 작업에서 출발하기
블로그의 HTML과 CSS를 수정할 때 날짜별 복사본을 남기면 처음에는 안심이 됩니다. 그러나 나중에는 어떤 두 파일이 짝인지, 무엇을 고쳤는지, 가장 안정적인 버전이 무엇인지 다시 찾아야 합니다. Git은 이 작업을 프로젝트의 이력으로 관리합니다. 설명을 붙인 커밋을 남겨 변경 이유와 당시의 파일 상태를 함께 찾을 수 있게 하는 것입니다.
Git과 GitHub는 같은 것이 아닙니다. Git은 로컬에서 이력을 관리하는 도구이고, GitHub는 저장소를 공유하고 협업할 수 있는 서비스입니다. 원격 저장소가 없어도 커밋과 이력 비교가 가능합니다. 다만 로컬 디스크 안에만 있는 저장소는 디스크 고장을 대비한 별도 백업이 아니므로 중요한 작업은 안전한 다른 위치에도 보관해야 합니다.
작업 폴더에서 바로 커밋으로 가지 않는다
파일을 수정한 상태, 다음 커밋에 포함하도록 선택한 상태, 실제 커밋된 상태를 구분합니다. git add는 현재 파일 내용을 스테이징 영역에 올립니다. 이후 같은 파일을 다시 고쳤다면 새 수정분은 자동으로 이미 준비된 커밋 내용에 들어가지 않습니다. 커밋 전에 git diff와 git diff --cached를 나누어 보는 이유입니다.
아래는 새 연습 저장소에서 skin.html과 style.css를 이미 만들어 둔 경우입니다. 실제 프로젝트에서 무작정 git add .를 실행하기보다 대상 파일을 지정하는 습관부터 시작합니다. 비밀번호, 환경 설정의 비밀값, 대형 빌드 산출물이 섞이지 않았는지 확인하세요. .gitignore는 앞으로 추적하지 않을 파일을 정하는 것이며 이미 기록된 비밀을 지워 주는 기능이 아닙니다.
예제 · bash
git init -b main
git config user.name "Example Developer"
git config user.email "developer@example.com"
git status
git add skin.html style.css
git diff --cached
git commit -m "Record initial blog layout"
git log --oneline기록이 읽히는 커밋 만들기
커밋은 ‘오늘 한 일 전부’보다 함께 검토하고 되돌릴 수 있는 단위가 좋습니다. 예를 들어 배경색 조정과 로그인 오류 수정은 별개 커밋으로 남기면 원인을 추적하기 쉽습니다. 메시지는 ‘수정’만 쓰기보다 무엇을 어떤 목적으로 바꿨는지 드러내세요. Git이 충돌 없이 합쳤다는 사실과 프로그램이 정상 작동한다는 사실은 다르므로 테스트도 필요합니다.
Git은 파일 상태의 스냅샷을 중심으로 이력을 관리하며 단순히 모든 줄의 수정 내역만 쌓아 두는 도구로 이해하면 부족합니다. 또한 .git 폴더를 지우면 해당 폴더의 이력과 설정을 잃을 수 있습니다. 고장이 의심된다고 먼저 지우거나 강제 초기화하지 말고 status와 diff, log로 상태를 확인하는 것부터 시작합니다.
참고 자료
예제는 학습용이며, 모든 환경에서 실행 검증된 완성 프로젝트는 아닙니다. 적용 전 사용 중인 버전과 프로젝트 환경에서 동작을 확인하세요.