1
git blame을 보조 문서 형식으로 사용하고 싶습니다. 커밋이 이루어진 이유와 언제 그리고 누구에 의해 확인되는지 정말 유용합니다.하나의 가지가 다른 것보다 역사에 더 관련이 있다는 사실을 인정하면
하지만 특정 행의 기록이 손실되는 경우가 있습니다. 이러한 상황이 발생할 수있는 몇 가지 상황 :
변경되었지만 되돌릴 수 있습니다.
누군가 파일을 다시 들여 쓰고 커밋합니다. 나중에 표준 들여 쓰기가 복원되고 커밋됩니다.
누군가 파일을 기록없이 새로운 지사/저장소로 복사합니다. 브랜치에 원래의 히스토리가 여전히 있습니다. 새 브랜치에 병합하고 싶습니다.
이 모든 경우에 git blame에는 파일의 최신 변경 사항이 표시되며 일반적으로 그다지 유용하지 않습니다. 예 : "들여 쓰기 복원"또는 "복귀 커밋 # 123"또는 "초기 커밋 : 모든 파일".
git blame에 힌트를주는 방법이 있습니까? 우리는 새로운 것보다 오래된 기록에 더 관심이 있습니까?
... - A - B - C
- 는이 파일의 모든 라인을위한 좋은 주석이 커밋 : 여기
상황이다.
- 커밋 B는 전체 파일에 다시 붙습니다.
.-------. / \ ... - A - B - C - D-
:
- C (아마도 되돌리기)은 우리가 마법의 자식이 우선 부모와 병합 수행 할 수 있는지 궁금 A.에게
커밋 된 방법에 파일을 복원 커밋
- 커밋 D는
git blame의 우선 순위가 A임을 나타냅니다. 내가 허용 찾을 것
또 다른 가능성 :
E - F
\
... - A - B - C - D
- 는 E 커밋은 비어있는 새 지점입니다.
- Commit F는 관심있는 파일 만 추가합니다.
- 커밋 D는 두 개의 이력을 병합하여 F를 이력의 우선 순위로 만듭니다.
저는 이것을 영구히 역사의 일부로 만들기를 희망합니다. 역사를 검색 할 때 git blame에 추가 옵션을 전달하는 데 정말로 관심이 없습니다.
접선 관찰 : 어제는 ** dev1 **과 ** dev2 ** 모두 동일한 3 행 수정을 해당 브랜치에 붙여 넣었습니다. (그들은 실제로 충돌하지 않기 때문에, git은 양쪽 브랜치에서 변경되는 줄을 신경 쓰지 않고 자동으로 병합 할 수 있습니다.) ** master **에 ** dev1 **의 분기를 어제 병합 시켰습니다. 젠장. 오늘 나는 ** dev2 **의 브랜치 (branch)를 ** master **로 합쳤고, ** dev2 **는 git blame으로 나타난다. 하지만'git merge -s ours dev2'를 사용하여 병합을하면 ** dev1 **이 ** dev2 **가 아닌 git blame에 나타납니다. 나는 여전히 희망이 있을지 모르겠다. :) – joeytwiddle