'git blame'은 무엇을 하는가?

314

사용 방법에 대한 많은 질문을 보았지만 git blame실제로 이해하지 못합니다.

내가 볼 BlameGitHub의 인터페이스에있는 파일의 상단에 버튼을 누릅니다. 그것을 클릭하면 왼쪽 막대에 사용자 이름이 약간 다릅니다. 그게 뭐야?

git blameGitHub와 별도로 실제로 사용되는 이유는 무엇 입니까?

git git-blame

— 히만 슈 미라
소스

66

"부끄러운"소리가 나도 당신을 위해 blamey, 당신은이 스크립트를 설치하고 git praise대신 사용할 수 있습니다 :) github.com/ansman/git-praise

— Jon Kiparsky

7

그것은 비난이나 칭찬이되어서는 안됩니다. 본질적으로 가정적이며 객관적이어야합니다.

— pdvries November

40

git objectively-determine-contributer같은 반지가 없습니다.

— Ritwik Bose

27

@RitwikBose 또는 단순히git who

— aktivb

238

에서 자식 비난 :

주어진 파일의 각 행에 마지막으로 수정 한 개정판의 정보를 표시합니다. 선택적으로 주어진 개정판에서 주석을 달기 시작합니다.

한 번 이상 지정된 경우 -L은 주석을 요청 된 행으로 제한합니다.

예:

johndoe@server.com:~# git blame .htaccess
...
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  4) allow from all
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  5)
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  6) <IfModule mod_rewrite.c>
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  7)     RewriteEngine On
...

참고 git blame연대기 의미에서 당 줄 변경 내역을 표시하지 않습니다. 마지막 커밋까지 문서에서 한 줄을 변경 한 사람 만 표시 HEAD합니다.

즉, 문서 라인의 전체 히스토리 / 로그를 보려면에서의 git blame path/to/file각 커밋마다을 실행해야 합니다 git log.

— 표
소스

1

그래서 마지막 사람을 보는 것입니까?

— Rıfat Erdem Sahin 님이

2

예, 회선을 변경 한 마지막 사람을 볼 수 있습니다.

— Mark

@Mark 그래서 IDE에 주석을 달 때 내부적으로 git blame 명령을 내립니까?

— Nagarajan Shanmuganathan

2

@NagarajanShanmuganathan 예, git을 사용하면 그 장면 뒤에서 일어나는 일입니다.

— Mark

151

명령이 잘 설명되어 있습니다. 당신은 할 수 있습니다 그것은, 공동 작업자가 특정 라인을 작성하거나 프로젝트를 파괴하는 알아낼의 비난 을 :)

— 엑스레이
소스

105

이 명령은 실제로 당신이 누군가를 비난하는 것처럼 들립니다 . 적어도 그것이 내가이 포스트에서 무엇을했는지 배우기 전에 나에게 들리는 방식이다.

— Francisco C.

12

@FranciscoC. 당신은 이것을 찾고 있습니다 : github.com/jayphelps/git-blame-someone-else

— DustWolf

2

@FranciscoC. 잠깐만 요, 정확히 그렇게하지 않습니까? 다른 사람 을 비난 할 수 있습니까?

— IanDess

16

@IanDess 아마도 의미론 일 뿐이지 만 git blame, 마치 git commit누가 어떤 변화가 있었는지 알려주는 것과 비슷한 효과가 지속되는 것처럼 들린다 . 그 단어와 "비난"이라는 단어의 부정적 의미는 멀리 떨어져 있어야 할 명령처럼 들리게하고 설명을 구하는 것과 같은 질문으로 이어집니다.

— Francisco C.

20

분명히 호출되어야합니다 git praise.

— pfnuesel

75

GitHub에서 :

비난 명령은 파일을 변경 한 사람을 결정하는 데 도움이되는 Git 기능입니다.

부정적 인 이름에도 불구하고 git blame은 실제로 무해합니다. 주요 기능은 누가 파일에서 어떤 행을 변경했는지, 왜 그런지를 지적하는 것입니다. 코드의 변경 사항을 식별하는 유용한 도구가 될 수 있습니다.

기본적으로 git-blame파일의 각 줄을 마지막으로 수정 한 개정 및 작성자를 표시하는 데 사용됩니다. 파일 개발 이력을 확인하는 것과 같습니다.

— 히만 슈 미라
소스

2

이것은 나에게 중복되는 것처럼 보입니다. 커밋 사이의 차이점과 커밋 로그에서 사용자를 식별 할 수 있습니다. 여기서 모든 것을 이해한다면 커밋 기록보다 지속성이 떨어집니다. 어쩌면 내가 놓친 것이 있지만 공개 굴욕을 통해 시행되는 코딩 표준처럼 보입니다.

— user1431356

8

나는 명령의 이름이 Linus의 유머 감각의 결과라고 생각합니다. :) 누군가를 모욕하는 데 사용되지는 않았습니다. :)

— Mladen B.

2

@ user1431356-요점은 특정 줄에 영향을주는 첫 번째 로그 줄을 원한다는 것 입니다. 그렇지 않으면 로그를 통해 특정 문자열을 검색해야합니다. (실제로 실행 가능한 접근 방법은 매뉴얼 페이지에서 "git log -S"를 참조하십시오.)

— azernik

1

"blame"타이틀은 git 전에 몇 년 동안 존재했던 것입니다. svn의 구현을 살펴보십시오 . Linus Torvalds가 지정한 이름이 아닙니다.

— JackAce

"나는 명령의 이름이 리누스의 유머 감각의 결과라고 생각한다. 누군가를 모욕하십시오.

— Sinaesthetic

34

이 git blame명령은 파일에 대한 최신 변경을 담당하는 커밋이 누구 / 누구인지 파악하는 데 사용됩니다. 각 라인의 저자 / 커밋도 볼 수 있습니다.

git blame filename (코드의 모든 줄에 대한 변경을 담당합니다)

git blame filename -L 0,10 ( "0"행에서 "10"행으로의 변경을 담당합니다)

비난에 대한 다른 많은 옵션이 있지만 일반적으로 도움이 될 수 있습니다.

— 바라 스 TS
소스

2

git blame명령 (Q2 2019), 그렇게 할 것입니다 힘내 2.22로 ... 마지막으로 라인을 수정 한 개정 정보로 라인을 주석하고 빠르게 "주위에 있기 때문에 성능 수정의, git blame어떤이있다 (특히 선형 역사" 우리는 최적화해야합니다).

David Kastrup ( )의 commit f892014 (2019 년 4 월 2 일)를 참조하십시오 . ^{(의해 병합}^{Junio C 하마노 -}^-^에^{커밋 4d8c4da}^{25 사월 2019)}fedelibre^gitster

blame.c: 원점 블랍을 간절히 삭제하지 마십시오

부모 블롭이 이미 비난을 위해 대기중인 청크를 가지고있는 경우, 한 블레 임 단계의 끝에 블롭을 삭제하면 즉시 다시로드되어 I / O의 양이 두 배가되고 선형 히스토리를 처리 할 때 언 패킹됩니다.

이러한 부모 블로 브를 메모리에 유지하는 것은 오래된 브랜치에서 병합을 처리 할 때 주로 추가 메모리 압력이 발생하는 합리적인 최적화처럼 보입니다.

— VonC
소스

1

이 git blame명령은 파일 내용을 한 줄씩 검사하고 각 줄이 마지막으로 수정 된시기와 수정 작성자를 확인하는 데 사용됩니다.

코드에 버그가 있었다면, 누가 버그를 식별했는지 파악한 후, 그를 비난 할 수 있습니다. 힘내 비난은 비난을 받는다.

한 줄 코드의 히스토리를 알아야 할 git log -S"code here"경우 git blame보다 간단한 것을 사용하십시오 .

자식 로그 대 자식 비난

— jackzhoumine
소스

'git blame'은 무엇을 하는가?

blame.c: 원점 블랍을 간절히 삭제하지 마십시오

`blame.c`: 원점 블랍을 간절히 삭제하지 마십시오