📌 깃랩에서 깃허브로 레포지토리 미러링하기!
이미 잘 나와있는 방법들이 많지만, 깃허브 push 후 변환과정에 대한 정보는 많이 없어서 기록하게 되었습니다! n시간의 고생끝에 얻은 결론!

1. 대용량 파일(100mb 이상)이 없는 경우

📌 요약
1) mirror 명령어로 깃랩레포 clone 받기
2) 해당 레포폴더로 이동
3) 깃허브에 새 레포 만들어두기 (이사할 집 만들어두기!)
4) 깃허브 새 레포 주소에 push

// 1)
git clone --mirror 깃랩 레포지토리 주소
git clone --mirror https://lab. ~~~ .git  // 예시 

// 2)
cd 레포지토리명.git

// 3)
git push --mirror 새 깃허브 레포 주소
git push --mirror https://github.com~~  // 예시

2. 대용량 파일이 있을 경우

📌 요약
1), 2), 3) 과정 동일
그냥 push를 시도할 경우 아래와 같은 error가 뜬다!

remote: error: this exceeds GitHub's file size limit of 100.00 MB

4) git-lfs 다운로드
5) bfg repo cleaner 다운로드
6) 대용량 파일 추적하기
7) 찾은 대용량 파일 -> bfg repo cleaner를 사용해서 정리하기
8) 깃허브로 push

(1) git-lfs 다운로드

git lfs install

🔥 git-lfs에 대한 자세한 포스팅!
대용량 파일 github에 push할 때 생기는 오류 정복하기(feat. git-lfs, bfg)

(2) bfg repo cleaner 다운로드

BFG Repo-Cleaner 홈페이지
다운로드는 레포지토리명.git과 같은 위치에 다운!

(3) 대용량 파일 추적하기

📌 대용량 파일 트래킹!
오류가 났던 파일의 확장자 적어주기!

git filter-branch --tree-filter 'git lfs track "*.{100MB 이상 파일 확장자명}"' -- --all

저는 특히 .tsx 파일들이 100mb가 넘는 경우가 많았었는데요, .png 파일 등 여러 종류의 파일들 또한 100mb가 넘는 경우가 있어서 모든 파일을 다 찾기로 했습니다!

모든 파일을 다 찾을 경우

git filter-branch --tree-filter 'git lfs track "*.*"' -- --all

모든 파일을 찾을 경우 시간이 정말 오래 걸립니다ㅠㅠ

마음을 느긋하게 먹고 2~3시간 다른 작업을 하다가 보면!

짠~ 오류가 났던 부분(100mb 이상의 파일)이 변환 되었습니다!

(4) bfg repo cleaner로 정리하기

📌 JDK 설치!
Liberica JDK 다운로드 또는
Oracle JDK 다운로드


📌모든 파일 검사 + bfg 파일 위치가 레포지토리명.git과 같은 위치일 경우

java -jar ../bfg-1.14.0.jar --convert-to-git-lfs '*.*'

📌특정 확장자 파일을 검사했을 경우 아래 코드를 확장자 개수 만큼 입력

java -jar BFG.jar저장경로 --convert-to-git-lfs '*.확장자'

(5) 깃허브로 push

git push --mirror 새로운깃허브주소

이제 변환된 파일들과 기존 파일, 커밋 기록 등을 깃허브로 push!
이것도 정~~말 오래오래 걸립니다....

3. lfs파일 변환하기

📌 2번까지 완료하고 나면 깃허브에 깃랩의 레포지토리가 잘 미러링 된 것을 확인할 수 있습니다! 그런데 레포지토리의 상태가 이상하다?

몇몇 파일들이 아래와 같은 요상한 문자로 변경되었습니다!

version https://git-lfs.github.com/spec/v1
oid sha256:a7axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
size 7122

이게 대체 무슨 뜻이지....??? 눈 앞이 캄캄해져서 chatGPT에게 물어봤습니다!

📌 해당 파일이 Git LFS(대용량 파일 스토리지)로 관리되고 있음을 나타냅니다.
Git LFS가 사용하는 프록시 파일로, 원본 파일의 메타데이터를 저장소에 저장한 상태입니다. 실제 파일 내용은 Git LFS 서버(GitHub의 LFS 스토리지)에 저장되어 있습니다. 원본 파일을 다운로드하려면 Git LFS를 사용해야 합니다.

💡 자세히

version https://git-lfs.github.com/spec/v1

Git LFS 스펙 1을 따르고 있다는 표시! Git LFS는 대용량 파일을 저장소에 직접 저장하지 않고, 메타데이터(참조 정보)를 저장소에 저장합니다.

oid sha256:...

OID(Object ID)는 파일의 내용을 기반으로 계산된 SHA-256 해시값! 파일의 고유한 식별자 역할을 합니다.

size 7122

원래 파일의 크기(바이트 단위)

결국 해당 파일은 lfs 메타데이터를 저장한 것이고, 원본 파일을 로컬에 다운로드 받아서 다시 commit, push 해야한다는 뜻이었습니다!

(1) 깃허브 레포지토리 clone하기

📌 깃랩 레포가 아닌! 깃허브 레포를 clone합니다

(2) lfs 파일을 로컬에 pull하고 목록 확인하기

lfs 파일들이 정상적으로 pull받아 진 것을 확인할 수 있습니다.

(3) add, commit, push

여기까지 하면, 깃허브에 파일들이 원래 형태로 변환된 것을 확인할 수 있습니다!!

🔥주의)

commit 시에 API Key 등 민감한 정보가 포함되어 있으면 깃허브 룰에 의해 오류가 납니다!!
먼저 해당 코드를 삭제하고 push까지 한 후에 .env 등으로 처리하는 것을 추천!!
(저는 lfs pull 상태에서 .env처리를 하려하니 계속 오류가 났었습니다ㅠㅠ)

💡깃허브 미러링 시 추가적인 문제점과 고찰

1. 전체 커밋 내역과 파일은 모두 가져왔으나(누락 없음),
   메인 화면에 보이는 커밋기록이 다소 섞임 (최신기록이 표시되어야하는데, 뒤죽박죽)
2. default 브랜치가 fix/~~ 이런 작업용 브랜치로 설정됨

✔️ 원인 (으로 추정)

(1) 깃랩의 default 브랜치(master)와 깃허브의 default 브랜치 (main)가 달라서 (처음에 설정해주지 않았었음. 새레포 만들고 설정 필요)
(2) 깃랩의 protected 브랜치 때문 (깃랩에서 풀 수 있지만, 무서워서 시도 해보지 않음)


📌 default 브랜치는 push후에도 바꿀 수 있지만, 메인 화면에 보이는 커밋 내역은 바꿀 수 없었습니다...ㅠㅠ
혹시 해결방법을 아시는 분이 계시다면 알려주세요...ㅠㅠ

✅ 레퍼런스

깃랩 레포지토리를 깃허브로 옮기기(feat. SSAFY)
대용량 파일 github에 push할 때 생기는 오류 정복하기(feat. git-lfs, bfg)