.git 폴더 축소 방법
현재 제 베이스의 총 크기는 약 200MB입니다.
하지만 내 .git 폴더는 5GB(!)라는 놀라운 크기를 가지고 있습니다.외부 서버에 작업을 푸시하기 때문에 큰 로컬 기록이 필요하지 않습니다.
.git 폴더를 축소하여 노트북의 공간을 확보하려면 어떻게 해야 합니까?30일보다 오래된 모든 변경사항을 삭제할 수 있습니까?
30일 이상 지난 변경 사항을 모두 삭제해서는 안 됩니다(어떻게든 Git을 악용할 수 있다고 생각하지만 실제로는 권장되지 않습니다).
전화할 수 있습니다.git gc --aggressive --prune저장소에서 가비지 수집을 수행하고 오래된 개체를 정리합니다.자주 변경되는 이진 파일(아카이브, 이미지, 실행 파일)이 많습니까?그것들은 보통 거대하게 이어집니다..git각잘못 됨)를 기억하십시오.
추가 정보:
위의 명령을 사용하는 것은 작업을 수행하는 것이지만 잘못된 관행으로 간주됩니다. 명령은 과 같습니다.
git repack -a -d -f --depth=250 --window=250
오래된 저장소는 시간이 오래 걸릴 수 있으며 하룻밤 사이에 시작할 수 있습니다.소스는 깃 라이너스를 직접 만든 사람입니다.
Git 리누스의 제작자는 Git repo를 축소하는 방법에 대해 다음과 같이 말합니다.
"gitgc --aggressive"와 동등하지만 *적절하게* 수행됨은 다음과 같은 것을 (밤새에) 수행하는 것입니다.
git repack -a -d --depth=250 --window=250여기서 깊이는 델타 체인이 얼마나 깊어질 수 있는지에 대한 것이고(오래된 역사를 위해 더 길게 만들 수 있습니다. - 공간 오버헤드의 가치가 있습니다.), 창은 각 델타 후보가 스캔하기를 원하는 개체 창이 얼마나 큰지에 대한 것입니다.
그리고 여기에 "-f" 플래그("오래된 델타 모두 삭제")를 추가하는 것이 좋습니다. 이제 실제로 이 플래그가 좋은 후보를 찾는지 확인하려고 하기 때문입니다.
출처: http://gcc.gnu.org/ml/gcc/2007-12/msg00165.html
이렇게 하면 저장소에 고립된 이진 데이터가 제거됩니까?"git repack"은 사용자가 repo에 체크인한 후 삭제한 이미지 또는 이진 데이터를 제거하지 않습니다.이러한 데이터를 저장소에서 영구적으로 삭제하려면 기록을 다시 작성해야 합니다.일반적인 예는 git에서 실수로 암호를 체크인하는 경우입니다.다시 돌아가서 일부 파일을 삭제할 수 있지만 그때부터 지금까지 기록을 다시 작성한 다음 원본에 새 보고서를 강제로 밀어넣어야 합니다.
저는 이것들을 시도했지만 제 저장소는 여전히 매우 넓었습니다.문제는 생성된 대용량 파일을 실수로 체크인했다는 것입니다.검색한 결과 생성된 대용량 파일을 쉽게 삭제할 수 있는 훌륭한 튜토리얼을 발견했습니다.이 튜토리얼을 통해 저장소를 60MB에서 1MB 미만으로 축소할 수 있었습니다.
업데이트됨:여기 블로그 게시물의 복사 붙여넣기 버전이 있습니다.
Git 저장소 축소 방법
우리의 주요 Git 저장소는 갑자기 크기가 커졌습니다.하룻밤 사이에 180MB(압축)로 증가하여 복제하는 데 시간이 오래 걸렸습니다.
그 이유는 분명했습니다. 누군가가, 어딘가에서, 어떤 때는, 어떻게든, 거대한 파일들을 저질러 놓았기 때문입니다.하지만 우리는 그 파일들이 어디에 있는지 전혀 몰랐습니다.
몇 시간의 시행착오와 연구 끝에 저는 다음과 같은 프로세스를 완성할 수 있었습니다.
- 대용량 파일 검색
- 리포지토리에서 치료합니다.
- 파일이 다시 다운로드되지 않도록 원격(GitHub) 저장소 수정
모든 팀 구성원이 새 복제본을 생성할 수 있다는 보장이 없는 한 이 프로세스를 시도해서는 안 됩니다.이 작업에는 기록 변경이 포함되며 저장소에 기여하는 모든 사용자는 새로 정리된 리포지토리를 풀다운한 후에 해당 리포지토리로 이동해야 합니다.
저장소 심층 복제
문제가 되는 리포지토리의 로컬 복제본이 아직 없는 경우 지금 생성합니다.
git clone remote-url
이제 저장소를 복제했을 수 있지만 모든 원격 지점이 없습니다.이는 적절한 '딥 클린'을 보장하기 위해 반드시 필요합니다.이를 위해서는 간단한 Bash 스크립트가 필요합니다.
#!/bin/bash
for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master`; do
git branch --track ${branch##*/} $branch
done
말 그대로 복사된 이 스크립트를 위해 StackOverflow에 있는 bigfish 덕분입니다.
합니다.chmod +x filename.sh그리고 나서 그것을 실행합니다../filename.sh이제 모든 원격 지점도 갖게 됩니다(Git에서 이 기능을 제공하지 않는 것은 유감입니다).
대용량 파일 검색
Antony Stubbs 덕분입니다. 그의 Bash 스크립트는 로컬 Git 저장소에서 가장 큰 파일을 식별하며 아래와 같이 말 그대로 복제됩니다.
#!/bin/bash
#set -x
# Shows you the largest objects in your repo's pack file.
# Written for osx.
#
# @see http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
# @author Antony Stubbs
# set the internal field spereator to line break, so that we can iterate easily over the verify-pack output
IFS=$'\n';
# list all objects including their size, sort by size, take top 10
objects=`git verify-pack -v .git/objects/pack/pack-*.idx | grep -v chain | sort -k3nr | head`
echo "All sizes are in kB. The pack column is the size of the object, compressed, inside the pack file."
output="size,pack,SHA,location"
for y in $objects
do
# extract the size in bytes
size=$((`echo $y | cut -f 5 -d ' '`/1024))
# extract the compressed size in bytes
compressedSize=$((`echo $y | cut -f 6 -d ' '`/1024))
# extract the SHA
sha=`echo $y | cut -f 1 -d ' '`
# find the objects location in the repository tree
other=`git rev-list --all --objects | grep $sha`
#lineBreak=`echo -e "\n"`
output="${output}\n${size},${compressedSize},${other}"
done
echo -e $output | column -t -s ', '
이전과 같이 이 스크립트를 실행하면 다음과 유사한 출력이 표시됩니다.
All sizes are in kB. The pack column is the size of the object, compressed, inside the pack file.
size pack SHA location
1111686 132987 a561d25105c79aa4921fb742745de0e791483afa 08-05-2012.sql
5002 392 e501b79448b9e970ab89b048b3218c2853fdfc88 foo.sql
266 249 73fa731bb90b04dcf79eeea8fdd637ba7df4c089 app/assets/images/fw/iphone.fw.png
265 43 939b31c563bd40b1ca70e4f4a9f7d67c27c936c0 doc/models_complete.svg
247 39 03514d9e84418573f26b205bae7e4e57057c036f unprocessed_email_replies.sql
193 49 6e601c4067aaddb26991c4bd5fbddef003800e70 public/assets/jquery-ui.min-0424e108178defa1cc794ee24fc92d24.js
178 30 c014b20b6fed9f17a0b2809ac410d74f291da26e foo.sql
158 158 15f9e56bc0865f4f303deff053e21909661a716b app/assets/images/iphone.png
103 36 3135e15c5cec75a4c85a0636b154b83221020c97 public/assets/application-c65733a4a64a1a885b1c32694574b12a.js
99 85 c1c80bc4c09e692d5e2127e39c87ecacdb1e816f app/assets/images/fw/lovethis_logo_sprint.fw.png
네 - 누군가가 다소 불필요한 파일을 어딘가에 밀어넣은 것 같습니다!사랑스러운 1.1 포함SQL 덤프 파일 형식으로 존재하는 GB입니다.
파일 정리
리포지토리 사용량에 따라 파일을 정리하는 데 시간이 좀 걸립니다.프로세스를 시작하려면 하나의 명령만 있으면 됩니다.
git filter-branch --tag-name-filter cat --index-filter 'git rm -r --cached --ignore-unmatch filename' --prune-empty -f -- --all
소스에서 으로, 으로 추가된 것은 " 명령은다소수서정다니습었되에이스른"입니다. 주요 추가 사항은 다음과 같습니다.--tag-name-filter cat태그도 다시 작성할 수 있습니다.
이 명령 실행이 완료되면 모든 분기와 태그가 그대로 있는 리포지토리를 치료해야 합니다.공간 회수
우리가 저장소의 기록을 다시 썼을 수도 있지만, 이러한 파일은 여전히 저장소에 존재하여 디스크 공간을 훔치고 일반적으로 성가시게 만듭니다.핵병기들을 핵으로 만들자꾸나
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now
이제 우리는 신선하고 깨끗한 저장소를 갖게 되었습니다.저 같은 경우에는 180MB에서 7MB로 올라갔습니다.
치료된 리포지토리 밀어넣기
이제 변경 사항을 원격 저장소에 다시 적용하여 다른 사람이 180MB 다운로드의 고통을 겪지 않도록 해야 합니다.
git push origin --force --all
그--all논쟁은 또한 당신의 모든 가지를 밀어냅니다.그래서 우리는 그 과정을 시작할 때 그들을 복제해야 했습니다.
그런 다음 새로 다시 작성된 태그를 누릅니다.
git push origin --force --tags
팀원들에게 말합니다.
는 리지토의로복있이는다사른다는용음자합중다니사를 해야 합니다.git rebase또는 새 복제본을 생성합니다. 그렇지 않으면 다시 밀어넣을 때 해당 파일이 해당 파일과 함께 푸시되고 저장소가 이전 상태로 재설정됩니다.
Git repo에서 .git 폴더를 축소하는 방법
요약
가장 위험하거나 가장 효과적이거나 가장 빠른 순서에서 더 위험하거나 덜 효과적이거나 가장 느린 순서로 수행합니다.
로 고는 다음과 .git lfs선은 다음이 있는 경우에만 적용됩니다.git lfs설된치. 하면 타사 응용 수 .Google에서 검색하면 타사 독립 실행형 응용 프로그램인 것을 확인할 수 있습니다. 당신이 으면이 .git lfs설치되었습니다. 해당 줄은 무시하십시오.여기서부터 이 답변 아래에 있는 내 의견을 참조하십시오.
이 테스트 결과는 다음과 같은 레포에 대한 것입니다.du -hs --exclude=.git .는 를하지않함총크나기타다니냅을 총 크기를 ..gitdir, 약 80GB, 그리고du -hs .git그것을 보여주었습니다..git폴더만 약 162GB에서 시작했습니다.
# Memory Saved
# Time it took in .git dir
# ------------ ------------
time git lfs prune # 1~60 min 62 GB
time git gc # 3 min < 1 GB
time git prune # 1 min < 1 GB
time git repack -a -d --depth=250 --window=250 # 2 min < 1 GB
# (Note: `--prune` does nothing extra here; `man git gc` says
# `--prune is on by default`)
time git gc --aggressive --prune # 1.25 hrs < 1 GB
보시다시피, 마지막 명령어는 매우 적은 이점을 얻기 위해 매우 오랜 시간이 걸리므로 실행하지도 마십시오.
또한, 의대안을 실행하는 것에 입니다.git lfs prune 전체를 삭제하는 것입니다..git/lfs대신 수동으로 디렉토리를 지정한 후 lfs(git Large File System) 컨텐츠를 처음부터 다시 가져옵니다.
주의: 실수로 전체 디렉터리를 삭제하지 마십시오! 이 보고서에 대한 모든 GIT 기록, 지점 및 커밋을 잃게 됩니다!다음만 삭제합니다..git/lfs디렉토리입니다.다음과 같은 방법으로 작동할 수 있습니다.
# 1. Delete the whole git lfs directory
rm -rf .git/lfs
# 2. Re-fetch the git lfs contents again from scratch.
# See my answer here: https://stackoverflow.com/a/72610495/4561887
# Option 1 (recommended): fetch (to the ".git/lfs" dir) AND check out just the
# git lfs files for just the one branch or commit you currently have
# checked-out.
# - this might download ~20 GB of data on a large corporate mono-repo
git lfs pull
# OR do this (these two commands do the exact same thing as `git lfs pull`)
git lfs fetch
git lfs checkout
# Option 2: fetch (to the ".git/lfs" dir) ALL git lfs files for ALL branches on
# the remote
# - this might download ~1000 GB of data on the same large corporate mono-repo
# as above
git lfs fetch --all
# Also check out, or "activate" the git lfs files for your currently-checked-out
# branch or commit, by updating all file placeholders or pointers in your
# active filesystem for the current branch with the actual files these git lfs
# placeholders point to.
git lfs checkout
에 대한 git lfs바로 위에 표시된 명령은 다음과 같은 다른 답변은 다음과 같습니다.기본 사용자로 사용하는 방법: , , , 와의 차이점은 무엇입니까?
세부 사항
먼저 .git 폴더에서 무엇이 그렇게 많은 공간을 차지하는지 알아야 합니다. 기술은 기반 유사)을 입니다.ncduNCurs Disk Usage(NCurs Disk Usage)입니다.다른 방법은 다음과 같습니다.
du -h --max-depth=1 .git
참고 사항:귀하의 보고서가 얼마나 큰지 확인하기 위해 귀하의 보고서를 포함하지 않습니다..git합니다.
du -h --max-depth=1 --exclude=.git .
위의 첫 번째 명령 출력 예:
$ du -h --max-depth=1 .git
158G .git/lfs
6.2M .git/refs
4.0K .git/branches
2.5M .git/info
3.7G .git/objects
6.2M .git/logs
68K .git/hooks
162G .git
의 총계는 보시피, 내총는입니다..git폴더 크기는 162 GB이지만, 그 중 158 GB는 내 것입니다..git/lfs타사 "Git Large File Storage"()git lfs 도구를 사용하여 대용량 이진 파일을 저장하고 있기 때문입니다.따라서 이를 실행하여 이를 크게 줄일 수 있습니다.참고: 더time아래의 모든 명령 중 일부는 선택 사항입니다.
time git lfs prune
(만약git lfs prune"vmx: 런타임 오류: 잘못된 메모리 주소 또는 nil 포인터 참조 취소"로 실패합니다. 아래의 참고 사항을 참조하십시오.)
출처: Git LFS repo 축소 방법
공식 문서: -- 로컬 저장소에서 이전 LFS 파일 삭제
그것은 뛰는 데 60초가 걸렸습니다!
이제 62GB의 용량을 확보했습니다!나의.git/lfs폴더는 다음과 같이 96GB에 불과합니다.
$ du -h --max-depth=1 .git
96G .git/lfs
6.2M .git/refs
4.0K .git/branches
2.5M .git/info
3.0G .git/objects
6.2M .git/logs
68K .git/hooks
99G .git
다음으로, 이것을 실행하여 다음을 축소합니다..git/objects~ 1: 예를 들어MB에서 최대 1GB까지 폴더 확장:
time git gc
time git prune
git gc약이며, 시간은 3분 정도입니다.git prune1분 정도 걸립니다.
다합확다니로 디스크 사용량을 다시 .du -h --max-depth=1 .git많은 하십시오.
time git repack -a -d --depth=250 --window=250
약 2분 정도 소요되며 수백 MB의 용량을 더 절약할 수 있습니다.
이제 여기서 중지하거나 다음 최종 명령을 실행할 수 있습니다.
time git gc --aggressive --prune
이 최종 명령은 수백 MB를 더 절약할 수 있지만 약 1.25시간이 소요됩니다.
한다면git lfs prune: 오류: 주소 포인터 해제"로합니다. "valid memory or nil pointer dereference "failure: failure nil": "failure"
한다면git lfs prune실패 대상:
패닉: 런타임 오류: 잘못된 메모리 주소 또는 nil 포인터 참조 취소
그러면 당신은 오래된 버전의git-lfs설치되었으며 업데이트해야 합니다.방법은 다음과 같습니다.
먼저 설치한 버전을 확인합니다.려달을 합니다.man git-lfs아래로 스크롤하여 날짜를 확인합니다.예를 들어, 2017년부터라고 쓰여 있을 수도 있습니다.이제 다음 명령으로 버전을 업데이트합니다.첫 번째 명령은 다음과 같습니다. https://packagecloud.io/github/git-lfs/install .
curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt update
sudo apt install git-lfs
려달을 합니다.man git-lfs다시 아래로 스크롤합니다.저는 이제 제 날짜를 2017년 어느 날짜였던 "2021년 3월"로 봅니다.
가 한또, 뛰면가를 하면,sudo apt install git-lfs다시 말하지만, 그것은 나에게 말합니다:
git-lfs는 이미 최신 버전(2.13.3)입니다.
그래서, 다음에 대한 업데이트.git-lfs가 사라졌고, 작했고오, 이는류사고졌라제동,▁worked이오졌고사라▁is,git lfs prune다시 작동합니다!
저는 이것을 GitHub에 대한 논평에서 처음으로 문서화했습니다: https://github.com/git-lfs/git-lfs/issues/3395#issuecomment-889393444 .
참조:
- @니틀:.git 폴더 축소 방법
- @데이비드 데건:.git 폴더 축소 방법
git lfs pruneGit LFS 레포 축소 방법- 리누스 토발스온
git repack -a -d --depth=250 --window=250: https://gcc.gnu.org/legacy-ml/gcc/2007-12/msg00165.html - https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-prune.1.ronn
참고 항목:
- 내 대답: Unix & Linux: 파일 크기를 기준으로 검색, 필터링 및 정렬에 대한 모든 내용 - 마지막에 있는 "(다음에 추가할 파일 확장명 파악)"이라는 제목의 예제를 참조하십시오.
- 기타 정말 유용합니다.
git lfs정보:- 좋은 글입니다!내 개발자 행성: Git LFS: 사용 이유 및 방법
- https://git-lfs.github.com/
- 나의 레포와 노트: https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles#how-to-clone-this-repo-and-all-git-submodules
- [my Q&A] 기본 사용자로서의 사용법: , , , 와의 차이점은 무엇입니까?
- [나의 Q&A] gitcheckout 실패 후 gitfs post checkout 후크 재개 방법
- 참고:동기화를 또는 "FreeFileSync"를 .
rsync여기 제 대답에서 설명한 바와 같이.그렇긴 하지만 가끔은git동기화를 위해서도 마찬가지입니다. 여기서 제 툴에 대해 설명하고 다른 답변을 드리겠습니다. SSH를 통해 Eclipse를 사용하여 원격 프로젝트를 수행하십시오.
좀 합니다.5GB와 200MB는 좀 이상합니다.실행시를 실행해 .git gc.
로 분할하지 수 ..git디렉토리입니다.
Git repo의 각 복제본은 서버 역할을 할 수 있는 완전한 저장소입니다.이것이 분산 버전 제어의 기본 원칙입니다.
파로 기록 제을 거여 에서 일부 파일
.git마지막 업데이트 시간을 기준으로 한 폴더입니다.
Local Machine에서도 동일한 문제가 발생했습니다.그 이유는 로컬에서 중앙 저장소로 커밋된 대용량 파일을 삭제했기 때문입니다.하지만 그 후의 이벤트git status,git fetch그리고.git pull.나의.git는 약입니다. 에 다음 하여 폴더크약기는 3GB니다의 . 나중다실크기줄를입다니여행하명령을음..git한 달 전에 변경/변경된 파일을 고려하여 폴더를 만듭니다.
명령
$ git remote prune origin && git repack && git prune-packed && git reflog expire --expire=1.month.ago && git gc --aggressive
Git 명령 및 명령에 대한 간단한 설명:
git-prune할 수 없는 합니다.git-repack저장소에 압축 해제된 개체 패킹git-prune-packed이미 팩 파일에 있는 추가 개체를 제거합니다.git reflogGit는 참조 로그 또는 "reflogs"라는 메커니즘을 사용하여 분기 끝에 대한 업데이트를 추적합니다.Reflogs는 Gitref가 로컬 리포지토리에서 업데이트된 시간을 추적합니다.분기 팁 리필로그 외에도 Gitstash에 대한 특수 리필로그가 유지됩니다.리프로그는 로컬 리포지토리의 디렉토리에 저장됩니다..gitdirectory는 git reflog 파일에서 수 ..git/logs/refs/heads/.,.git/logs/HEAD그리고 또한.git/logs/refs/stashgit stash가 repo에 사용된 경우.git reflog를 페이지에서 높은 수준으로 기록합니다.
git reflog expire --expire=now --expire-unreachable=now --all
리프로그에 기록을 보존하는 것 외에도 Git는 분리된 커밋을 제거할 내부 만료 날짜를 가지고 있습니다.다시 말씀드리지만, 이것들은 모두 구현 세부 사항입니다.git gc및 들핸및git prune독립 실행형으로 사용해서는 안 됩니다.git gc --aggressive깃-gc - 불필요한 파일을 정리하고 로컬 리포지토리를 최적화합니다.
뒤서에 gitgc는과 같은 명령 합니다.git prune, git repack, git pack and git rerere은 이한 명높 수의 책임 에설 임레 계다 벗것니 입하는 에서 설정된 임계값 하는 것입니다.git gc배열. 에 따라됩니다.식별된 개체는 압축되거나 그에 따라 제거됩니다.
결과가 포함된 공통 광고:
$ git remote prune origin && git repack && git prune-packed && git reflog expire --expire=1.month.ago && git gc --aggressive
Enumerating objects: 535, done.
Counting objects: 100% (340/340), done.
Delta compression using up to 2 threads
Compressing objects: 100% (263/263), done.
Writing objects: 100% (340/340), done.
Total 340 (delta 104), reused 0 (delta 0)
Enumerating objects: 904, done.
Counting objects: 100% (904/904), done.
Delta compression using up to 2 threads
Compressing objects: 100% (771/771), done.
Writing objects: 100% (904/904), done.
Total 904 (delta 343), reused 561 (delta 0)
버전 기록보다는 동기화 메커니즘으로 git를 더 많이 사용하고 있습니다.따라서 이 문제에 대한 제 해결책은 현재 소스가 모두 만족스러운 상태인지 확인한 다음 .git를 삭제하고 저장소를 다시 초기화하는 것이었습니다.디스크 공간 문제가 해결되었습니다. :-) History gone :-( 제 레포가 작은 USB 키에 있기 때문에 이렇게 합니다.나는 나의 모든 역사를 원하거나 필요로 하지 않습니다.만약 제가 역사를 잘라내는 방법이 있다면, 저는 그것을 사용할 것입니다.
내 기록을 보관하는 데 관심이 있다면 현재 저장소를 보관할 것입니다.나중에 원래 저장소를 복제하고 새 저장소의 모든 변경 사항을 복사할 수 있습니다(이름 변경 또는 삭제 작업을 많이 하지 않았다고 가정해 보겠습니다).그런 다음 새로운 레포의 모든 변경 사항을 이전 레포의 단일 커밋으로 나타내는 하나의 큰 커밋을 만듭니다.기록을 병합할 수 있습니까?아마도 내가 브랜치를 사용한 후에 필요하지 않은 물건들을 삭제했다면. (나는 git 내부자들에 대해 그렇게 장난을 치기 시작할 만큼 충분히 알지 못합니다.)
위의 방법을 시도했지만, 제 경우에는 아무 것도 작동하지 않았습니다(깃 푸시 중에 실수로 깃 프로세스를 죽였습니다). 그래서 저는 마침내 레포를 삭제하고 다시 복제해야 했고 지금은 .git 폴더의 크기가 정상입니다.
가장 좋은 옵션은 BFG Repo Cleaner를 사용하는 것입니다(BitBucket에서 권장하고 다른 옵션은 훨씬 빠르게 실행할 수 있습니다). https://rtyley.github.io/bfg-repo-cleaner/
또한 저는 Steve Lorek의 솔루션을 사용하려고 시도했고 그것도 작동합니다: https://web.archive.org/web/20190207210108/http ://stevelorek.com/how-to-shrink-a-git-repository.html
언급URL : https://stackoverflow.com/questions/5613345/how-to-shrink-the-git-folder
'programing' 카테고리의 다른 글
| com.google.common.util.current 클래스가 중복됩니다.들을 수 있는모듈 guava-20.0.jar(com.google.guava:guava:20.0)에서 미래가 발견되었습니다. (0) | 2023.07.15 |
|---|---|
| Postgre에 대한 장고 연결SQL: "피아 인증 실패" (0) | 2023.07.15 |
| Vuex에서 사용자 지정 개체 메서드를 사용하는 방법은 무엇입니까? (0) | 2023.07.15 |
| 원격 저장소에서 로컬 Git 분기를 삭제한 후 삭제 (0) | 2023.07.15 |
| 빠른 로그 기준 2개의 상한 계산 (0) | 2023.07.15 |