Git LFS란 무엇입니까?
Git은 분산된 버전 제어 시스템입니다. 즉, 복제 프로세스 중에 리포지토리의 전체 기록이 클라이언트로 전송됩니다. 대용량 파일, 특히 정기적으로 수정되는 대용량 파일을 포함하는 프로젝트의 경우 클라이언트에서 모든 파일의 모든 버전을 다운로드해야 하므로 초기 복제에는 상당한 시간이 걸릴 수 있습니다. Git LFS(Large File Storage)는 Atlassian, GitHub 및 기타 오픈 소스 기여자가 개발한 Git 확장 프로그램으로 관련 버전을 대용량으로 다운로드하여 리포지토리에 있는 대용량 파일의 영향을 줄입니다. 특히 대용량 파일은 복제하거나 가져오는 중에 다운로드되는 것이 아니라 체크아웃 프로세스에서 다운로드됩니다.
Git LFS는 리포지토리의 대용량 파일을 작은 포인터 파일로 대체하여 이 작업을 수행합니다. 일반적으로 사용하는 동안에는 포인터 파일이 Git LFS에서 자동으로 처리되므로 이러한 파일을 볼 수 없습니다.
1. 리포지토리에 파일을 추가하면 Git LFS는 파일의 콘텐츠를 포인터로 대체하고 로컬 Git LFS 캐시에 저장합니다.
관련 자료
전체 Git 리포지토리를 이동하는 방법
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
2. 새 커밋을 서버에 푸시하면 새로 푸시한 커밋에서 참조하는 모든 Git LFS 파일은 로컬 Git LFS 캐시에서 Git 리포지토리에 연결된 원격 Git LFS 저장소로 전송됩니다.
Git LFS 포인터가 포함된 커밋을 체크아웃하면 로컬 Git LFS 캐시에 있는 파일로 대체되거나 원격 Git LFS 저장소에서 다운로드됩니다.
Git LFS는 원활하게 작동합니다. 작업 복사본에서는 실제 파일 콘텐츠만 표시됩니다. 따라서 기존 Git 워크플로를 변경하지 않고 Git LFS를 사용할 수 있으므로 평소처럼 git checkout, 편집, git add, git commit을 하면 됩니다. 지금까지 존재했던 파일의 모든 버전이 아닌 실제로 체크아웃한 커밋에서 참조하는 대용량 파일의 버전만 다운로드하므로 git clone 및 git pull 작업은 훨씬 빨라집니다.
Git LFS를 사용하려면 Bitbucket Cloud 또는 Bitbucket Data Center와 같은 Git LFS 인식 호스트가 필요합니다. 리포지토리 사용자는 Git LFS 명령줄 클라이언트를 설치하거나 Sourcetree와 같은 Git LFS 인식 GUI 클라이언트가 필요합니다. 흥미로운 사실: Sourcetree를 발명한 Atlassian 개발자인 Steve Streeting은 Git LFS 프로젝트의 주요 기여자이기도 하므로 Sourcetree와 Git LFS는 함께 잘 작동합니다.
Git LFS 설치
1. Git LFS를 쉽게 설치하는 세 가지 방법이 있습니다.
a. 즐겨 사용하는 패키지 매니저를 사용하여 설치합니다. git-lfs 패키지는 Homebrew, MacPorts, dnf 및 packagecloud에서 사용할 수 있습니다.
b. 프로젝트 웹사이트에서 Git LFS를 다운로드하여 설치합니다.
c. Git LFS와 함께 번들로 제공되는 무료 Git GUI 클라이언트인 Sourcetree를 설치합니다.
2. 경로에 git-lfs가 있으면 git lfs install을 실행하여 Git LFS를 초기화합니다(Sourcetree를 설치한 경우 이 단계를 건너뛸 수 있음).
$ git lfs install Git LFS initialized. git lfs install은 한 번만 실행하면 됩니다. 시스템에서 초기화된 후 Git LFS 콘텐츠가 포함된 리포지토리를 복제하면 Git LFS가 자동으로 부트스트랩합니다.
새 Git LFS 리포지토리 만들기
Git LFS 인식 리포지토리를 새로 만들려면 리포지토리를 만든 후에 git lfs install을 실행해야 합니다.
# initialize Git
$ mkdir Atlasteroids
$ cd Atlasteroids
$ git init
Initialized empty Git repository in /Users/tpettersen/Atlasteroids/.git/
# initialize Git LFS
$ git lfs install
Updated pre-push hook.
Git LFS initialized.그러면 git push를 할 때 Git LFS 파일을 서버로 전송하는 특별한 pre-push Git 후크가 리포지토리에 설치됩니다.
Git LFS는 모든 Bitbucket Cloud 리포지토리에서 자동으로 사용 설정되어 있습니다. Bitbucket Data Center의 경우 리포지토리 설정에서 Git LFS를 사용 설정해야 합니다.
리포지토리에 대해 Git LFS가 초기화되면 git lfs track을 사용하여 추적할 파일을 지정할 수 있습니다.
기존 Git LFS 리포지토리 복제
Git LFS가 설치되면 git clone을 사용하여 평소와 같이 Git LFS 리포지토리를 복제할 수 있습니다. 복제 프로세스 마지막에 Git은 기본 브랜치(보통 main)를 체크아웃하고 체크아웃 프로세스를 완료하는 데 필요한 Git LFS 파일이 자동으로 다운로드됩니다. 예를 들면 다음과 같습니다.
$ git clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 31.00 KiB/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Downloading Assets/Sprites/projectiles-spritesheet.png (21.14 KB)
Downloading Assets/Sprites/productlogos_cmyk-spritesheet.png (301.96 KB)
Downloading Assets/Sprites/shuttle2.png (1.62 KB)
Downloading Assets/Sprites/space1.png (1.11 MB)
Checking out files: 100% (81/81), done.이 리포지토리에는 Git LFS에서 추적하는 PNG가 네 개 있습니다. git clone을 실행하면 포인터 파일이 리포지토리에서 체크아웃될 때 Git LFS 파일이 한 번에 하나씩 다운로드됩니다.
복제 속도 향상
LFS 파일이 많은 리포지토리를 복제하는 경우 명시적 git lfs clone 명령을 사용하면 향상된 성능을 누릴 수 있습니다.
$ git lfs clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MBGit LFS 파일을 한 번에 하나씩 다운로드하는 대신 git lfs clone 명령은 체크아웃이 완료될 때까지 기다렸다가 필요한 Git LFS 파일을 일괄 다운로드합니다. 병렬 다운로드의 이점을 활용하여 HTTP 요청 및 프로세스의 수가 크게 줄어듭니다(Windows의 성능 개선에 특히 중요함).
풀 및 체크아웃
복제와 마찬가지로 일반적인 git pull을 사용하여 Git LFS 리포지토리에서 풀할 수 있습니다. 풀이 완료되면 필요한 Git LFS 파일은 자동 체크아웃 프로세스의 일부로 다운로드됩니다.
$ git pull
Updating 4784e9d..7039f0a
Downloading Assets/Sprites/powerup.png (21.14 KB)
Fast-forward
Assets/Sprites/powerup.png | 3 +
Assets/Sprites/powerup.png.meta | 4133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 4136 insertions(+)
create mode 100644 Assets/Sprites/projectiles-spritesheet.png
create mode 100644 Assets/Sprites/projectiles-spritesheet.png.metaGit LFS 콘텐츠를 가져오는 데 명시적인 명령은 필요하지 않습니다. 하지만 예상치 못한 이유로 체크아웃이 실패하면 git lfs pull을 사용하여 현재 커밋에 누락된 Git LFS 콘텐츠를 다운로드할 수 있습니다.
$ git lfs pull
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB풀 속도 향상
git lfs clone과 마찬가지로 git lfs pull은 Git LFS 파일을 일괄 다운로드합니다. 마지막으로 풀한 이후로 많은 파일이 변경된 경우 체크아웃 중에 자동 Git LFS 다운로드를 사용 중지하고 명시적인 git lfs pull을 사용하여 Git LFS 콘텐츠를 일괄 다운로드할 수 있습니다. 이 작업은 git pull을 호출할 때 -c 옵션으로 Git 구성을 재정의하여 수행할 수 있습니다.
$ git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull입력할 것이 많기 때문에 간단한 Git 별칭을 만들어 Git과 Git LFS 풀을 일괄 수행하는 것도 좋습니다.
$ git config --global alias.plfs "\!git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull"
$ git plfs이렇게 하면 많은 Git LFS 파일을 다운로드해야 할 때(다시 강조하자면 특히 Windows에서) 성능이 크게 향상됩니다.
Git LFS로 파일 추적
리포지토리에 새로운 유형의 대용량 파일을 추가할 때는 git lfs track 명령으로 패턴을 지정하여 이를 추적하도록 Git LFS에 지시해야 합니다.
$ git lfs track "*.ogg"
Tracking *.ogg"*.ogg" 주변의 따옴표가 중요합니다. 따옴표를 생략하면 셸에서 와일드카드가 확장되고 현재 디렉터리에 있는 각 .ogg 파일에 대해 개별 항목이 만들어집니다.
# probably not what you want
$ git lfs track *.ogg
Tracking explode.ogg
Tracking music.ogg
Tracking phaser.oggGit LFS에서 지원하는 패턴은 .gitignore에서 지원하는 패턴과 같으며, 예를 들어 다음과 같습니다.
# track all .ogg files in any directory
$ git lfs track "*.ogg"
# track files named music.ogg in any directory
$ git lfs track "music.ogg"
# track all files in the Assets directory and all subdirectories
$ git lfs track "Assets/"
# track all files in the Assets directory but *not* subdirectories
$ git lfs track "Assets/*"
# track all ogg files in Assets/Audio
$ git lfs track "Assets/Audio/*.ogg"
# track all ogg files in any directory named Music
$ git lfs track "**/Music/*.ogg"
# track png files containing "xxhdpi" in their name, in any directory
$ git lfs track "*xxhdpi*.png이러한 패턴은 git lfs track 명령을 실행한 디렉터리와 관련이 있습니다. 단순하게 유지하려면 리포지토리의 루트에서 git lfs track을 실행하는 것이 가장 좋습니다. 참고로 Git LFS는 .gitignore와는 달리 네거티브 패턴을 지원하지 않습니다.
git lfs track을 실행하면 명령을 실행한 디렉터리에 .gitattributes라는 새 파일이 생깁니다. .gitattributes는 특수 동작을 특정한 파일 패턴에 바인딩하는 Git 메커니즘입니다. Git LFS는 추적된 파일 패턴을 Git LFS 필터에 바인딩하기 위해 .gitattributes 파일을 자동으로 만들거나 업데이트합니다. 그러나 .gitattributes 파일에 대한 변경 사항은 리포지토리에 직접 커밋해야 합니다.
$ git lfs track "*.ogg"
Tracking *.ogg
$ git add .gitattributes
$ git diff --cached
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..b6dd0bb
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.ogg filter=lfs diff=lfs merge=lfs -text
$ git commit -m "Track ogg files with Git LFS"편리한 유지 관리를 위해 항상 리포지토리의 루트에서 git lfs track을 실행하여 모든 Git LFS 패턴을 하나의 .gitattributes 파일에 보관하는 것이 가장 간단합니다. 하지만 인수 없이 git lfs track을 호출하여 현재 Git LFS(그리고 패턴이 정의되어 있는 .gitattributes 파일)에서 추적하고 있는 모든 패턴의 목록을 표시할 수 있습니다.
$ git lfs track
Listing tracked paths
*.stl (.gitattributes)
*.png (Assets/Sprites/.gitattributes)
*.ogg (Assets/Audio/.gitattributes).gitattributes 파일에서 해당 줄을 제거하거나 git lfs untrack 명령을 실행하여 Git LFS로 특정 패턴의 추적을 중단할 수 있습니다.
$ git lfs untrack "*.ogg"
Untracking *.ogg
$ git diff
diff --git a/.gitattributes b/.gitattributes
index b6dd0bb..e69de29 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1 +0,0 @@
-*.ogg filter=lfs diff=lfs merge=lfs -textgit lfs untrack 명령을 실행한 후에 다시 변경 사항을 .gitattributes에 직접 커밋해야 합니다.
커밋 및 푸시
평소처럼 Git LFS 콘텐츠가 포함된 리포지토리에 커밋하고 푸시할 수 있습니다. Git LFS에서 추적하는 파일에 변경 사항을 커밋한 경우 Git LFS 콘텐츠가 서버로 전송될 때 git push에서 추가 출력이 표시됩니다.
$ git push
Git LFS: (3 of 3 files) 4.68 MB / 4.68 MB
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.16 KiB | 0 bytes/s, done.
Total 8 (delta 1), reused 0 (delta 0)
To git@bitbucket.org:tpettersen/atlasteroids.git
7039f0a..b3684d3 main -> main어떤 이유로든 LFS 파일 전송이 실패하면 푸시가 중단되며 안전하게 다시 시도할 수 있습니다. Git과 마찬가지로 Git LFS 저장소는 콘텐츠 주소 지정이 가능하여 콘텐츠 자체의 SHA-256 해시인 키에 콘텐츠가 저장됩니다. 따라서 Git LFS 파일을 항상 안전하게 서버로 다시 전송할 수 있으며 실수로 Git LFS 파일의 콘텐츠를 잘못된 버전으로 덮어쓸 일이 없습니다.
호스트 간 Git LFS 리포지토리 이동
한 호스팅 공급자에서 다른 호스팅 공급자로 Git LFS 리포지토리를 마이그레이션하려면 --all option을 지정하여 git lfs fetch와 git lfs push를 조합하여 사용할 수 있습니다.
예를 들어 모든 Git 및 Git LFS 리포지토리를 github라는 원격 리포지토리에서 bitbucket이라는 원격 리포지토리로 이동하려면 다음을 수행합니다. 😉
# create a bare clone of the GitHub repository
$ git clone --bare git@github.com:kannonboy/atlasteroids.git
$ cd atlasteroids
# set up named remotes for Bitbucket and GitHub
$ git remote add bitbucket git@bitbucket.org:tpettersen/atlasteroids.git
$ git remote add github git@github.com:kannonboy/atlasteroids.git
# fetch all Git LFS content from GitHub
$ git lfs fetch --all github
# push all Git and Git LFS content to Bitbucket
$ git push --mirror bitbucket
$ git lfs push --all bitbucket추가 Git LFS 기록 가져오기
일반적으로 Git LFS는 사용자가 로컬에서 실제로 체크아웃하는 커밋에 필요한 파일만 다운로드합니다. 하지만 git lfs fetch --recent 명령을 사용하여 Git LFS에서 최근에 수정한 다른 브랜치에 대한 추가 콘텐츠를 다운로드하도록 할 수 있습니다.
$ git lfs fetch --recent
Fetching main
Git LFS: (0 of 0 files, 14 skipped) 0 B / 0 B, 2.83 MB skipped Fetching recent branches within 7 days
Fetching origin/power-ups
Git LFS: (8 of 8 files, 4 skipped) 408.42 KB / 408.42 KB, 2.81 MB skipped
Fetching origin/more-music
Git LFS: (1 of 1 files, 14 skipped) 1.68 MB / 1.68 MB, 2.83 MB skipped점심 시간에 새 Git LFS 콘텐츠를 일괄 다운로드하거나 팀원들의 작업을 검토할 계획인데 제한된 인터넷 연결로 인해 나중에 콘텐츠를 다운로드할 수 없는 경우에 유용합니다. 예를 들어, 비행기에 탑승하기 전에 git lfs fetch --recent 명령을 실행할 수 있습니다!
Git LFS는 7일 이내의 커밋이 포함된 브랜치나 태그를 최근으로 간주합니다. lfs.fetchrecentrefsdays 속성을 설정하여 최근으로 간주되는 기간을 구성할 수 있습니다.
# download Git LFS content for branches or tags updated in the last 10 days
$ git config lfs.fetchrecentrefsdays 10기본적으로 git lfs fetch --recent는 브랜치 또는 태그의 끝에 있는 커밋에 대한 Git LFS 콘텐츠만 다운로드합니다.
그러나 lfs.fetchrecentcommitsdays 속성을 구성하면 최근 브랜치와 태그의 이전 커밋에 대한 콘텐츠를 다운로드하도록 Git LFS를 구성할 수 있습니다.
# download the latest 3 days of Git LFS content for each recent branch or tag
$ git config lfs.fetchrecentcommitsdays 3이 설정은 주의해서 사용하세요. 브랜치가 빠르게 이동하는 경우 엄청난 양의 데이터가 다운로드될 수 있습니다. 하지만 브랜치에서 전체적인 변경 사항을 검토하거나 브랜치에서 커밋을 cherry pick해야 하거나 기록을 다시 작성해야 하는 경우에는 유용할 수 있습니다.
호스트 간 Git LFS 리포지토리 이동에서 설명한 것처럼 git lfs fetch --all을 사용하여 리포지토리의 모든 Git LFS 콘텐츠를 가져오도록 선택할 수도 있습니다.
$ git lfs fetch --all
Scanning for all objects ever referenced...
✔ 23 objects found
Fetching objects...
Git LFS: (9 of 9 files, 14 skipped) 2.06 MB / 2.08 MB, 2.83 MB skipped로컬 Git LFS 파일 삭제
git lfs prune 명령을 사용하여 로컬 Git LFS 캐시에서 파일을 삭제할 수 있습니다.
$ git lfs prune
✔ 4 local objects, 33 retained
Pruning 4 files, (2.1 MB)
✔ Deleted 4 files그러면 이전 파일로 간주되는 로컬 Git LFS 파일이 삭제됩니다. 이전 파일이란 다음에서 참조하지 않는 파일입니다.
- 현재 체크아웃된 커밋
- 아직 푸시되지 않은 커밋(origin으로 또는
lfs.pruneremotetocheck이 설정된 항목) - 최근 커밋
기본적으로 최근 커밋은 지난 10일 동안 만들어진 커밋으로, 다음 항목을 더해서 계산됩니다.
추가 Git LFS 기록 가져오기에서 설명한 lfs.fetchrecentrefsdays 속성의 값(기본값은 7)lfs.pruneoffsetdays속성의 값(기본값은 3)
Git LFS 콘텐츠를 더 오랜 기간 동안 보관하도록 정리 오프셋을 구성할 수 있습니다.
# don't prune commits younger than four weeks (7 + 21)
$ git config lfs.pruneoffsetdays 21Git에서 기본 제공되는 가비지 컬렉션과는 다르게 Git LFS 콘텐츠는 자동으로 정리되지 않으므로 로컬 리포지토리 크기를 줄이려면 정기적으로 git lfs prune을 실행하는 것이 좋습니다.
git lfs prune --dry-run으로 정리 작업이 어떤 영향을 미치는지 시험해볼 수 있습니다.
$ git lfs prune --dry-run
✔ 4 local objects, 33 retained
4 files would be pruned (2.1 MB)그리고 정확히 어떤 Git LFS 개체를 git lfs prune --verbose --dry-run으로 정리할지 시험해볼 수 있습니다.
$ git lfs prune --dry-run --verbose
✔ 4 local objects, 33 retained
4 files would be pruned (2.1 MB)
* 4a3a36141cdcbe2a17f7bcf1a161d3394cf435ac386d1bff70bd4dad6cd96c48 (2.0 MB)
* 67ad640e562b99219111ed8941cb56a275ef8d43e67a3dac0027b4acd5de4a3e (6.3 KB)
* 6f506528dbf04a97e84d90cc45840f4a8100389f570b67ac206ba802c5cb798f (1.7 MB)
* a1d7f7cdd6dba7307b2bac2bcfa0973244688361a48d2cebe3f3bc30babcf1ab (615.7 KB)--verbose 모드에서 출력되는 긴 16진수 문자열은 정리할 Git LFS 개체의 SHA-256 해시(개체 ID 또는 OID라고도 함)입니다. Git LFS 개체를 참조하는 경로 또는 커밋 찾기에서 설명한 기법을 사용하여 정리할 개체에 대해 자세히 알아볼 수 있습니다.
안전하게 추가로 확인하기 위해 --verify-remote 옵션을 사용하여 Git LFS 개체를 정리하기 전에 원격 Git LFS 저장소에 복사본이 있는지 확인할 수 있습니다.
$ git lfs prune --verify-remote
✔ 16 local objects, 2 retained, 12 verified with remote
Pruning 14 files, (1.7 MB)
✔ Deleted 14 files이렇게 하면 정리 프로세스가 상당히 느려지지만 정리된 개체는 서버에서 복구할 수 있으므로 안심할 수 있습니다. lfs.prunverifyremotealways 속성을 전역적으로 구성하면 시스템에 --verify-remote 옵션을 영구적으로 사용 설정할 수 있습니다.
$ git config --global lfs.pruneverifyremotealways true 또는 위의 명령에서 --global 옵션을 생략하여 컨텍스트 리포지토리에만 원격 확인을 사용 설정할 수 있습니다.
서버에서 원격 Git LFS 파일 삭제
Git LFS 명령줄 클라이언트는 서버에서 파일 정리를 지원하지 않으므로 파일을 삭제하는 방법은 호스팅 공급자에 따라 다릅니다.
Bitbucket Cloud에서는 리포지토리 설정 > Git LFS를 통해 Git LFS 파일을 보고 삭제할 수 있습니다.
참고로 각 Git LFS 파일은 SHA-256 OID로 색인화되며 각 파일을 참조하는 경로는 UI를 통해 표시되지 않습니다. 그 이유는 주어진 개체를 참조할 수 있는 커밋에 아주 많은 경로가 있을 수 있기 때문입니다. 따라서 경로를 찾는 프로세스는 매우 느릴 것입니다.
주어진 Git LFS 파일에 실제로 무엇이 포함되어 있는지 확인하는 데는 세 가지 방법이 있습니다.
- Bitbucket Git LFS UI의 왼쪽 열에 있는 파일 미리 보기 이미지와 파일 형식을 확인
- Bitbucket Git LFS UI의 오른쪽 열에 있는 링크를 사용하여 파일을 다운로드 -다음 섹션에서 설명하는 것처럼 Git LFS 개체의 SHA-256 OID를 참조하는 커밋을 검색
Git LFS 개체를 참조하는 경로 또는 커밋 찾기
Git LFS SHA-256 OID가 있으면 git log --all -p -S 를 사용하여 이를 참조하는 커밋을 확인할 수 있습니다.
$ git log --all -p -S 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
commit 22a98faa153d08804a63a74a729d8846e6525cb0
Author: Tim Pettersen <tpettersen@atlassian.com>
Date: Wed Jul 27 11:03:27 2016 +1000
Projectiles and exploding asteroids
diff --git a/Assets/Sprites/projectiles-spritesheet.png
new file mode 100755
index 0000000..49d7baf
--- /dev/null
+++ b/Assets/Sprites/projectiles-spritesheet.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
+size 21647git log 명령은 지정된 문자열(Git LFS SHA-256 OID)이 포함된 줄(-S)을 추가하거나 제거하는 브랜치(--all)의 커밋에서 패치(-p)를 생성합니다.
패치에 LFS 개체에 대한 커밋과 경로, 추가한 사용자, 커밋된 시간이 표시됩니다. 간단하게 커밋을 체크아웃하면 필요한 경우 Git LFS가 파일을 다운로드하여 작업 복사본에 넣습니다.
특정 Git LFS 개체가 현재 HEAD 또는 특정 브랜치에 있다고 생각하는 경우 git grep을 사용하여 해당 개체를 참조하는 파일 경로를 찾을 수 있습니다.
# find a particular object by OID in HEAD
$ git grep 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc HEAD
HEAD:Assets/Sprites/projectiles-spritesheet.png:oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
# find a particular object by OID on the "power-ups" branch
$ git grep e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4 power-ups
power-ups:Assets/Sprites/shield2.png:oid sha256:e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4HEAD 또는 power-ups를 Git LFS 개체가 포함된 참조, 커밋 또는 트리로 바꿀 수 있습니다.
Git LFS 파일 포함/제외
일부 상황에서는 특정 커밋에 사용할 수 있는 Git LFS 콘텐츠 중 일부만 다운로드하고 싶을 수도 있습니다. 예를 들어, 단위 테스트를 실행하도록 CI 빌드를 구성할 때는 소스 코드만 있으면 되므로 코드를 빌드하는 데 필요하지 않은 무거운 파일은 제외하고 싶을 것입니다.
git lfs fetch -X(또는 --exclude)를 사용하여 패턴이나 하위 디렉터리를 제외할 수 있습니다.
$ git lfs fetch -X "Assets/**" 또는 특정 패턴이나 하위 디렉터리만 포함시킬 수도 있습니다. 예를 들어, 오디오 엔지니어는 git lfs fetch -I(또는 --include)로 ogg 및 wav 파일만 가져올 수 있습니다.
$ git lfs fetch -I "*.ogg,*.wav" 포함과 제외를 조합하여 사용하면 포함 패턴과 일치하고 또한 제외 패턴과 일치하지 않는 파일만 가져오게 됩니다. 예를 들어, 다음과 같이 gifs를 제외하고 Assets 디렉터리에 있는 모든 것을 가져올 수 있습니다.
$ git lfs fetch -I "Assets/**" -X "*.gif" 제외 및 포함은 git lfs track 및 .gitignore와 동일한 패턴을 지원합니다. lfs.fetchinclude 및 lfs.fetchexclude 구성 속성을 설정하면 특정 리포지토리에 대해 이러한 패턴을 영구적으로 만들 수 있습니다.
$ git config lfs.fetchinclude "Assets/**"
$ git config lfs.fetchexclude "*.gif"--global 옵션을 추가하여 시스템의 모든 리포지토리에 이 설정을 적용할 수도 있습니다.
Git LFS 파일 잠금
안타깝게도 바이너리 병합 충돌을 쉽게 해결하는 방법은 없습니다. Git LFS 파일 잠금을 사용하면 확장자 또는 파일 이름으로 파일을 잠글 수 있으며 병합 중에 바이너리 파일을 덮어쓰지 못하게 할 수 있습니다.
LFS의 파일 잠금 기능을 활용하려면 먼저 어떤 유형의 파일을 잠글 수 있는지 Git에 알려야 합니다. 아래 예시에서 `--lockable` 플래그가 `git lfs track` 명령에 추가되며 둘 모두 PSD 파일을 LFS에 저장하고 잠금 가능으로 표시합니다.
$ git lfs track "*.psd" --lockable그런 다음 .gitattributes 파일에 다음을 추가합니다.
*.psd filter=lfs diff=lfs merge=lfs -text lockableLFS 파일 변경을 준비할 때 lock 명령을 사용하여 Git 서버에 잠긴 파일로 등록하게 됩니다.
$ git lfs lock images/foo.psd
Locked images/foo.psd파일 잠금이 더 이상 필요하지 않으면 Git LFS의 unlock 명령으로 제거할 수 있습니다.
$ git lfs unlock images/foo.psdGit LFS 파일 잠금은 git push와 비슷하게 --force 플래그를 사용하여 재정의할 수 있습니다. 수행하는 작업에서 조금이라도 이해되지 않는 부분이 있다면 --force 플래그를 사용하지 마세요.
$ git lfs unlock images/foo.psd --force이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
