아마 이런 느낌.
※자꾸 쓰고 공개해 버렸지만, 좀 더 자세하게 보충했습니다(2013/09/15 17:13)

각각 설명해 보자

HEAD^[n]

git log에서 출력되는 변경 내역 (커밋 로그)을 참조하십시오.
이 경우의 n은, 「n번째의 부모 커밋」의 뜻.git merge 빗질했을 경우에 병합 원이 되고 있는 부모 브랜치가 복수 있었을 경우에 n로 지정해 가는 것 같습니다.
나가 사용하고 있는 리포지토리로 시험하면..

HEAD~[n]

HEAD^2에서 출력되는 변경 내역 (커밋 로그)을 참조하십시오.
이 경우의 n은, 「n세대째의 부모 커밋」의 뜻.
기본적으로는 (이 경우는 기점을 HEAD로서) git log 의 타임 라인을 거슬러 올라가는 이미지로 n 을 이용할 수 있습니다. 요컨대, git log 와 git show HEAD^^^^ 는 동의.

HEAD@{[n]}

git show HEAD~4를 참조한다. Git을 조작한 기록이 이루어지고, 그것 베이스.
reflog는 HEAD의 움직임을 기록하고 있는 것으로, Git에 추적되고 있는 파일의 조작으로 무언가 실수를 한 경우에 git reflog 아직 이를 이용하는 상황에 빠진 적은 없습니다).

결론

무언가 일어났을 때 제대로 대처할 수 있도록, 이 떡의 차이를 이해하면 좋을 것 같습니다.

참고

Git 초보자가 절대 기억해야 할 명령 - idesaku blog

git의 상대 커밋 지정, 커밋 범위 지정 방법 - Linux, Mac, Emacs에 대한 설정, 기억

Junio ​​C Hamano: 입문 Git , 히데와 시스템, 2009