Git 리파지토리의 이력이 많아지거나, 리파지토리 용량이 클수록 clone을 받는데, 시간도 많이 걸리고 스토리지도 많이 필요하게 됩니다. 그래서 리파지토리의 일부 이력만 받아오는 방법이 있는데, 이를 전문용어로 shallow clone 이라고 합니다. 얕은 클론이라고 해석할 수 있는데, 이걸 기억하면 옵션도 쉽게 기억할 수 있습니다. 옵션이 depth거든요.
shallow clone
앞에서도 설명했드시 Git 리파지토리의 전체 이력 중 일부만 받아오는 행위를 shallow clone이라고 합니다. 그 반대, 즉 전체 이력을 받아오는 것을 deep clone (깊은 클론)이라고 합니다. 대개의 경우, 전체 이력을 받아오지만, 리파지토리가 매우 크거나, 오랜동안 쌓인 이력이 매우 많을 경우, 또는 요즘은 흔치 않지만, 네트워크 속도가 너무 느려 받아오는 도중 끊어지는 현상이 발생할 때 사용합니다.
방법은 받아올 때, depth 옵션을 주는 것입니다. 값은 받아올 이력의 갯수를 지정합니다. 1의 경우 가장 마지막 커밋만 받아오고 10을 줄 경우 10개의 커밋을 받아오게 됩니다. 요즘 가장 핫한 deno를 클론 받아서 한번 비교해보겠습니다.
( deno 프로젝트는 3491개 커밋이 있고, 전체크기는 약 20Mb입니다. )
# case 1 : depth=1
$ git clone --depth=1 https://github.com/denoland/deno.git
# case 2 : depth=10
$ git clone --depth=10 https://github.com/denoland/deno.git
# case 3 : deep clone
$ git clone https://github.com/denoland/deno.git결과를 보면 다음과 같습니다.
case 1: depth=1
case 2: depth=10
case 3: deep
클론을 받는데 소요시간은 case1, 2는 약 3.5초로 유의미한 차이는 없어보이고, case 3는 약 5초로 전체 이력을 받아오는데 더 많은 시간이 걸리는 것을 알 수 있습니다.
클론 받은 리파지토리의 용량을 비교해보면 역시나, deep 클론을 받은 리파지토리가 가장 많은 스토리지를 사용하는 것을 알 수 있습니다.
각각의 이력을 확인해보면 1개, 10개, 그리고 이력 전부를 확인할 수 있습니다.
시간도 적게 걸리고, 디스크도 덜 사용하는데, 왜 shallow 클론을 사용하지 않고, deep 클론을 하는 것일까요? 요새는 스토리지가 매우 넉넉하고, 네트워크 속도도 충분히 빠르기 때문에? 그것도 이유가 될 수 있지만 그것보다 근본적인 이유가 있습니다.
side effect.
shallow 클론이 장점만 갖지는 않습니다. 현재 개발된 코드를 확인하고 실행해 보는 데는, shallow 클론은 확실히 장점을 가집니다. 하지만 부작용이 있습니다. 코드를 수정하고 push 하려고 하면 Git 이력을 확인할 수 없고, 이 수정된 코드가 어떤 이력으로 만들어졌다는 것을 확인할 수 없기에 push가 거부될 수 있습니다. 따라서 해당 코드를 가지고 개발하는 사람이라면 shallow 클론을 해서는 안됩니다.
solution.
shallow 클론을 한 이후에, deep클론을 했던 것처럼, 이력을 더 받아올 수 있는 방법이 있습니다. 바로 unsallow 옵션을 주는 fetch 해 오는 것입니다.
$ git fetch --unshallow
만약 네트워크 속도 때문에 문제가 되는 상황이라면, 조금씩 더 받아오는 방법도 있습니다.
$ git fetch --depth 100
$ git fetch --depth 200
...
정리.
얕은 클론이 시간과 공간을 절약해 줄 수는 있지만, 그 효과는 미미하다고 할 수 있고, push를 할 수 없게 되는 불상사가 발생할 수 있으니 부득이한 상황이 아니면, 그냥 deep 클론을 하는 것이 좋습니다.