Git clone --depth=1 이후에 히스토리 복원하기.

Git 리파지토리의 이력이 많아지거나, 리파지토리 용량이 클수록 clone을 받는데, 시간도 많이 걸리고 스토리지도 많이 필요하게 됩니다. 그래서 리파지토리의 일부 이력만 받아오는 방법이 있는데, 이를 전문용어로 shallow clone 이라고 합니다. 얕은 클론이라고 해석할 수 있는데, 이걸 기억하면 옵션도 쉽게 기억할 수 있습니다. 옵션이 depth거든요. shallow clone 앞에서도 설명했드시 Git 리파지토리의 전체 이력 중 일부만 받아오는 행위를 shallow clone이라고 합니다. 그 반대, 즉 전체 이력을 받아오는 것을 deep clone (깊은 클론)이라고 합니다. 대개의 경우, 전체 이력을 받아오지만, 리파지토리가 매우 크거나, 오랜동안 쌓인 이력이 매우 많을 경우, 또는 요즘은 ..

페어 코딩 하시나요? ( GitHub에 공동 작업자 기록하기 )

페어 코딩을 할 기회가 종종 있습니다. 페어 코딩을 하게 되면 좋은 점이 있는데요. 물론 나쁜 점도 있어요. 이 얘기는 나중 더 자세히 적을 기회가 있을 것 같습니다. 아무튼 페어 코딩을 종종 하는데, 이때 공동 작업자를 기록하기가 애매합니다. 기본 적으로 Git에는 저자를 한 명 기록하게 돼있으니까요, 하루는 이 사람, 하루는 저 사람으로 기록하는 규칙을 정하자니 뭔가 불편합니다. ( 사실 이렇게도 해봤는데, 서로 자기 이름을 기록하지 않으려 하더라고요. ) 그래서 공동작업을 기록하는 방법을 찾아보기로 했습니다. 우선 저는 GitHub을 사용하고, 리눅스, 혹은 Mac에서 주로 개발합니다. 지금 설명하는 방법은 윈도우에서는 해보지 않았습니다. ( 되겠죠? 뭐 ) 그럼 공동 작업을 기록하는 방법을 찾아서..

뽀대나는 커밋 만들기 ( Signed Commit )

GitHub에서 소스코드를 보다 보면 종종 아래 그림과 같은 Verified라는 배지가 붙은 커밋을 볼 수 있습니다. 작성자가 커밋에 본인이 직접 작성한 것이라고 서명(Sign)한 커밋을 나타 냅니다. 이러한 서명은 gpg 인증을 통해서 할 수 있는데, 커밋을 어떻게 하여야 하며, GitHub에서는 어떻게 하는지 설명합니다. 왜 커밋에 사인을 해야 하는가? Git을 처음 접했을 때, 가졌던 의문 중 하나가 왜? 커밋의 작성자에 대한 검증을 하지 않는가? 였습니다. 좀 더 설명해 보자면 git을 처음 설치하게 되면 대부분 다음과 같은 설정을 하게 됩니다. git config --global user.email bitlog@tistory.com git config --gloabl user.name bitlo..