히스토리 읽기: log, diff, show 및 과거 탐색
프로젝트 히스토리는 단순한 로그가 아니라 결정의 기록입니다. 커밋을 필터링하고, 버전 간 변경 사항을 확인하며, SHA-1 해시를 두려움 없이 이해하는 방법을 배워 정보를 유용하게 읽어 냅니다. '좋은 히스토리'와 '나쁜 히스토리'를 구별하는 방법도 따로 다루는데, 이는 팀 내에서 어떻게 평가받는지에 직접적인 영향을 줍니다.
- 저장소 히스토리를 읽고 작성자, 날짜 또는 키워드로 원하는 커밋을 빠르게 찾을 수 있습니다.
- 작업 디렉토리, 인덱스, 커밋 등 다양한 수준에서 파일 버전을 비교하는 방법을 이해합니다.
- 업계 표준(Conventional Commits)에 따라 커밋 메시지를 작성하는 방법을 배웁니다.
Phần đầu bài giảng
커밋 히스토리: 프로젝트의 일기장
- Git log는 히스토리를 뒤집힌 일기장처럼 보여줍니다
- 각 항목은 변경 사항의 스냅샷입니다
- 누가, 언제, 무엇을 변경했는지 저장합니다
- 코드의 진화 과정을 볼 수 있습니다
Git에 변경 사항을 저장할 때마다 개발 일기에 기록을 남긴다고 상상해 보세요. 'git log' 명령어는 이러한 기록을 최신순에서 오래된 순으로 역순으로 보여줍니다. 이 일기에는 프로젝트의 전체 연대기가 저장되어 있습니다: 누가, 언제, 어떤 수정을 했는지 말이죠. 이것은 단순한 변경 목록이 아니라 여러분 코드 진화의 살아있는 역사입니다. 이 히스토리를 읽고 분석하는 능력은 팀 작업을 위한 핵심 기술입니다. 결국 커밋 히스토리를 통해 프로젝트가 어떻게 발전해 왔는지, 어떤 결정이 내려졌고 그 이유는 무엇인지 알 수 있습니다. 이제 개별 커밋의 구조를 자세히 살펴보겠습니다.
커밋 기록 읽기: 해시, 작성자, 날짜
- commit: 고유한 해시 식별자
- Author: 변경을 한 사람과 시기
- Date: 커밋의 타임스탬프
- 메시지: 무엇을 변경했는지
'git log' 명령어의 출력을 살펴보세요. 각 항목은 긴 문자열로 시작합니다. 이것이 바로 커밋 해시, 즉 고유 식별자입니다. 그 옆에는 변경한 사람과 날짜가 표시됩니다. 아래에는 변경 사항 저장 시 개발자가 작성한 커밋 메시지가 있습니다. 형식에 주목하세요: 먼저 꺾쇠 괄호 안에 작성자의 이메일이 있고, 그 다음에 타임스탬프가 옵니다. 이 데이터는 변경 사항의 맥락을 이해하고 필요한 경우 작성자에게 연락하여 확인하는 데 도움이 됩니다. 이제 커밋 구조를 살펴보았으니, 해시가 무엇이고 왜 필요한지 알아보겠습니다.
#!/bin/bash
cd ~/projects/git-course/
git log -1 --pretty=format:'commit %H%nAuthor: %an <%ae>%nDate: %ad%n%n %s'
커밋 해시: 히스토리를 여는 열쇠
- 해시는 커밋의 디지털 지문입니다
- 내용과 메타데이터에 따라 달라집니다
- 단 한 글자만 변경되어도 해시가 바뀝니다
- 모든 버전을 정확히 참조할 수 있습니다
커밋 해시는 무작위 문자 집합이 아니라, 커밋 내용을 고유한 문자열로 변환하는 암호화 함수의 결과입니다. 커밋에서 단 1바이트라도 변경하면 해시가 완전히 바뀝니다. 이는 변경 히스토리의 무결성을 보장합니다. 해시를 알면 책의 책갈피처럼 코드의 모든 버전을 참조할 수 있습니다. 예를 들어, 'git checkout' 명령어에 해시를 지정하면 해당 커밋 당시의 프로젝트 상태로 이동합니다. 이는 변경 사항을 되돌리거나 오류가 언제 발생했는지 분석해야 할 때 특히 유용합니다. 이제 히스토리 구조를 이해했으니, 실제 프로젝트에서는 커밋이 수천 개에 달할 수 있으므로 필터링하는 방법을 배워보겠습니다.
Bài giảng đầy đủ dành cho thuê bao
Còn 26 slide nữa trong phiên bản đầy đủ.
Video, toàn bộ slide, ghi chú, bài kiểm tra, gia sư AI và phỏng vấn sẽ mở sau khi đăng nhập và đăng ký thuê bao.
Đăng nhập hoặc đăng ký Đăng ký thuê baoNội dung bài giảng
- 커밋 히스토리: 프로젝트의 일기장
- 커밋 기록 읽기: 해시, 작성자, 날짜
- 커밋 해시: 히스토리를 여는 열쇠
- 작성자의 커밋을 찾는 방법
- 커밋 날짜별 필터링
- 커밋 텍스트 검색
- 필터 결합
- 커밋 로그 보기의 문제점
- --oneline을 사용한 간결한 표시
- --graph로 브랜치 시각화
- --all로 전체 그림 보기
- git diff란 무엇이며 왜 필요한가
- 작업 디렉토리의 변경 사항 비교
- 커밋할 준비가 된 것: git diff --staged
- 임의의 두 커밋 비교
- 특정 커밋을 자세히 분석하는 방법
- 실습: 커밋의 변경 사항 살펴보기
- 커밋 내 특정 파일 보기
- 파일의 최근 변경 사항 검색
- 히스토리를 통한 타인 코드 분석
- 함수 추가 또는 삭제 검색
- 커밋 메시지가 중요한 이유
- 이상적인 커밋 메시지 구조
- Conventional Commits 실전 적용
- 나쁜 커밋 메시지 리팩토링
- 'fix' 커밋이 안티패턴인 이유
- 변경의 원자성: 하나의 커밋, 하나의 작업
- git add -p: 깔끔한 커밋을 위한 구원의 도구
- 요약 및 과제
Bài viết liên quan đến bài học này
- Lệnh Git: bảng tra cứu với ví dụ dùng hằng ngày
- git log, diff, show và blame: cách đọc lịch sử dự án trong Git
- git bisect: cách tìm commit làm hỏng code
- Git và GitHub: khác nhau thế nào và liên hệ ra sao
- Cách cài đặt Git trên Windows, macOS và Linux
Tất cả bài giảng của khóa học
- 소개: 완전 초보에서 자신 있는 개발자로 성장하기 위한 Git
- Git가 왜 필요한가? — 취업에 왜 필수인가
- Git 설치 및 설정: 첫 실행을 위한 준비
- 첫 번째 저장소: init, add, commit과 인덱스의 마법
- 히스토리 읽기: log, diff, show 및 과거 탐색
- 브랜치: 코드의 평행 현실
- 오류 취소하기: restore, reset, revert — 올바른 방법과 위험한 방법
- GitHub 및 원격 저장소: 클라우드에 코드 저장하기
- 팀워크: 포크, 기능 브랜치 및 풀 리퀘스트
- 병합 충돌: 당황하지 말고 이해하고 해결하기
- 실제 팀의 Git 프로세스: 어떤 워크플로우를 선택할까
- 고급 도구: 리베이스, 스태시, 체리픽 및 태그
- 최종 프로젝트: 실제 팀 개발 시뮬레이션