히스토리 읽기: log, diff, show 및 과거 탐색
프로젝트 히스토리는 단순한 로그가 아니라 결정의 기록입니다. 커밋을 필터링하고, 버전 간 변경 사항을 확인하며, SHA-1 해시를 두려움 없이 이해하는 방법을 배워 정보를 유용하게 읽어 냅니다. '좋은 히스토리'와 '나쁜 히스토리'를 구별하는 방법도 따로 다루는데, 이는 팀 내에서 어떻게 평가받는지에 직접적인 영향을 줍니다.
- 저장소 히스토리를 읽고 작성자, 날짜 또는 키워드로 원하는 커밋을 빠르게 찾을 수 있습니다.
- 작업 디렉토리, 인덱스, 커밋 등 다양한 수준에서 파일 버전을 비교하는 방법을 이해합니다.
- 업계 표준(Conventional Commits)에 따라 커밋 메시지를 작성하는 방법을 배웁니다.
Simula ng leksyon
커밋 히스토리: 프로젝트의 일기장
- 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' 명령어에 해시를 지정하면 해당 커밋 당시의 프로젝트 상태로 이동합니다. 이는 변경 사항을 되돌리거나 오류가 언제 발생했는지 분석해야 할 때 특히 유용합니다. 이제 히스토리 구조를 이해했으니, 실제 프로젝트에서는 커밋이 수천 개에 달할 수 있으므로 필터링하는 방법을 배워보겠습니다.
Buong leksyon ay para sa subscription
26 pang slide sa buong bersyon.
Mabubuksan ang video, lahat ng slide, tala, pagsusulit, AI tutor, at interview pagkatapos mag-sign in at mag-subscribe.
Mag-sign in o magparehistro Mag-subscribeNilalaman ng leksyon
- 커밋 히스토리: 프로젝트의 일기장
- 커밋 기록 읽기: 해시, 작성자, 날짜
- 커밋 해시: 히스토리를 여는 열쇠
- 작성자의 커밋을 찾는 방법
- 커밋 날짜별 필터링
- 커밋 텍스트 검색
- 필터 결합
- 커밋 로그 보기의 문제점
- --oneline을 사용한 간결한 표시
- --graph로 브랜치 시각화
- --all로 전체 그림 보기
- git diff란 무엇이며 왜 필요한가
- 작업 디렉토리의 변경 사항 비교
- 커밋할 준비가 된 것: git diff --staged
- 임의의 두 커밋 비교
- 특정 커밋을 자세히 분석하는 방법
- 실습: 커밋의 변경 사항 살펴보기
- 커밋 내 특정 파일 보기
- 파일의 최근 변경 사항 검색
- 히스토리를 통한 타인 코드 분석
- 함수 추가 또는 삭제 검색
- 커밋 메시지가 중요한 이유
- 이상적인 커밋 메시지 구조
- Conventional Commits 실전 적용
- 나쁜 커밋 메시지 리팩토링
- 'fix' 커밋이 안티패턴인 이유
- 변경의 원자성: 하나의 커밋, 하나의 작업
- git add -p: 깔끔한 커밋을 위한 구원의 도구
- 요약 및 과제
Mga artikulo tungkol sa araling ito
- Mga command ng Git: cheat sheet na may mga halimbawa para sa araw-araw
- git log, diff, show, at blame: paano basahin ang history ng project sa Git
- git bisect: paano hanapin ang commit na sumira sa code
- Git at GitHub: ano ang pagkakaiba at paano sila magkaugnay
- Paano mag-install ng Git sa Windows, macOS, at Linux
Lahat ng leksyon ng kurso
- 소개: 완전 초보에서 자신 있는 개발자로 성장하기 위한 Git
- Git가 왜 필요한가? — 취업에 왜 필수인가
- Git 설치 및 설정: 첫 실행을 위한 준비
- 첫 번째 저장소: init, add, commit과 인덱스의 마법
- 히스토리 읽기: log, diff, show 및 과거 탐색
- 브랜치: 코드의 평행 현실
- 오류 취소하기: restore, reset, revert — 올바른 방법과 위험한 방법
- GitHub 및 원격 저장소: 클라우드에 코드 저장하기
- 팀워크: 포크, 기능 브랜치 및 풀 리퀘스트
- 병합 충돌: 당황하지 말고 이해하고 해결하기
- 실제 팀의 Git 프로세스: 어떤 워크플로우를 선택할까
- 고급 도구: 리베이스, 스태시, 체리픽 및 태그
- 최종 프로젝트: 실제 팀 개발 시뮬레이션