반응형
깃을 쓰다보면 하나의 파일이 이때까지 어떻게 변해 온건지를 파악해야할 때가있다.
예를 들어 지금 본인의 프로젝트에 있는 README파일도 모든 내용을 한번에 다 쓰고 커밋한게 아니다
지금 README파일은 여러번의 커밋을 해온 결과가 지금의 모습이다.
한 가지 파일이 완성되기까지 어떤 커밋들이 있어왔는지를 볼수있는 커맨드가 있다,
git blame
blame은 비난하다, ~의 탓으로 돌리다 이런 뜻인데
표현이 조금 그렇지만 여기서는 어떤 파일의 특정 코드를 누가 작성했는지 찾아내기 위해 사용된다.
아마 커맨드 개발자가 누군가 실수할 때 작성자를 갈구고 탓을 돌리기 위해 작명을 blame으로 작성했던것 같다(?)
git blame [파일명]
실행하면 파일의 각 부분이 어떤 커밋으로 인해 탄생했는지 한눈에 볼 수있다.
왼쪽에 영어 숫자 섞여있는건 뭔가 낯선데 맞다. 커밋아이디이다.
그옆에 SeopE는 이름이라고 볼 수있긴한데 다른 방법으로 자세히 보자면
git show [커밋아이디]
기억 할지 모르겠지만 어느 글에서 이 커맨드도 써본적이 있다
show 뒤에 커밋아이디 4자리 작성하고 실행해보면
이름 옆에 이메일이 나왔으니 이제 좀 더 자세히 알 수있게 된다.
이런식으로 협업을 위한 도구로써 책임감 있으면서 코드를 작성할 수있게 신중해야한다.
한번 작성한 커밋은 이렇게 나중에 다 조사대상이 되어 탓을 피할 수없게 된다....
반응형
'Git' 카테고리의 다른 글
(23) Git - reflog / reset 되돌리는 방법 (0) | 2024.09.11 |
---|---|
(실무_4) Git Part2 - git revert / 리모트 레포지토리에 올라간 커밋 취소하기 (0) | 2024.09.11 |
(실무_2) Git Part2 - git pull 와 git fetch (0) | 2024.09.10 |
(실무_1) Git Part2 - git push 전 git pull 하기 (0) | 2024.09.10 |
Git (17)~(22) 커맨드 정리 (0) | 2024.09.10 |