디스코드 베스트 포스트 추천 봇 만들기 4편 - 프로덕션 올리기전 시크릿 제거하기 bfg-repo-cleaner 와 커밋이 2배로 늘어나버린 문제
Description: 기존의 커밋을 bfg-repo-cleaner툴을 이용해지원보고, 그 과정에서 두 환경을 동작하며 생긴 커밋이 중복 추가된 경우를 해결해봅니다
현재 노트: KR-110.00 d 디스코드 베스트 포스트 추천 봇 만들기 4편 - 프로덕션 올리기전 시크릿 제거하기 bfg-repo-cleaner 와 커밋이 2배로 늘어나버린 문제
상위 분류: KR-110.00 디스코드 베스트 포스트 추천 봇 제작기
디스코드 베스트 포스트 추천 봇 만들기 4편 - 프로덕션 올리기전 시크릿 제거하기 bfg-repo-cleaner 와 커밋이 2배로 늘어나버린 문제
본 글의 내용은 일반적으로 다음과 같은 흐름으로 진행됩니다.
원하는 것을 구현 시도 -> 문제가 생김 -> 해결
또다른 기능등 시도-> 다시 새로운 문제가 생김 -> 해결
... 구현 또는 수정이나 해결될 때까지 적절하게 반복
결론
프라이빗 레포를 퍼블릭으로 돌리는 과정, 그 과정에서 혹시나 싶어 시크릿이 하드코딩된 커밋을 제거하는과정, 그 과정에서 커밋이 일부분 2배로 늘어나서 하나하나 수정하는 과정이 있었습니다.
private 깃헙 레포 로그인 정보저장하기
프라이빗 레포라 pull과같은 원격레포작업시마다 인증정보 요구
해당명령어를 통해 로그인 정보 저장가능(명령어 사용 후 한번 더 로그인 필요)
단 평문저장이라 보안상 위험한곳이라면 다른 방법 사용
cat ~/.git-**credentials 하면 다보임
로그인 정보 저장 명령어
git config --global credential.helper store
bfg-repo-cleaner 로 이미 올라가 있는 커밋 이력 청소하기
먼저 시크릿 판단여부
디스코드의 USER ID 18자리를 하드코딩해서 사용했음. 기존의 프라이빗 레포에서 퍼블릭으로 돌리려하는데 해당 값이 시크릿인지부터 판단.
결론적으로는 아닌것같긴함. 왜냐하면 따로 특별한 권한까지는 필요없기 때문. 하지만 나랑 직접적인 연관을 지을 수 있는 정보라 시크릿으로 취급하는 것이 좋겠다 + 나중에 만약 정말 반드시 지워야하는 시크릿이 있을경우를 대비한 문제를 해결해본다는 마인드로 도전
일단 비슷한 문제를 겪는 사람도 많고, 그를 위한 프로그램인 BFG-REPO-CLEANER를 많이 추천함.
일반적인 옵션인 --replace-text 옵션이 단일 문자열만 되는 줄 알았는데, reg패턴이나 또는 파일도 가능한 것을 알게됨. 즉 임시로 내가 없애고싶은 값들만 적어놓은 password.txt를 이용해서 해당 값이 감지되는 경우는 전부 커밋에서 제거됨
모든 커밋 sha값이 바뀜!!
해당 프로그램은 마치 force push처럼 새로운 커밋들로 밀어버리면서 그중에 원하는 것을 편집하는 형태인데, 변경사항이 없더라도 새로 push이기때문에 모든 커밋 히스토리가 무조건 다 바뀜
bfg실행결과 HEAD는 수정 불가 및 수정된 커밋들, 변경된 파일을 보여줌.
User@DESKTOP MINGW64 ~/Desktop/Project/bfg_cleaner
$ java -jar bfg-1.14.0.jar --replace-text password.txt some_example_repo.git/
Using repo : C:\Users\User\Desktop\Project\bfg_cleaner\some_example_repo.git
Found 12 objects to protect
Found 2 commit-pointing refs : HEAD, refs/heads/main
Protected commits
-----------------
These are your protected commits, and so their contents will NOT be altered:
* commit [PROTECTED_HASH] (protected by 'HEAD')
Cleaning
--------
Found 70 commits
Cleaning commits: 100% (70/70)
Cleaning commits completed in 152 ms.
Updating 1 Ref
--------------
Ref Before After
-------------------------------------
refs/heads/main | [OLD_HASH] | [NEW_HASH]
Updating references: 100% (1/1)
...Ref update completed in 16 ms.
Commit Tree-Dirt History
------------------------
Earliest Latest
| |
.......................................Dm.Dmmmmmmmmmmmmmmmmm
D = dirty commits (file tree fixed)
m = modified commits (commit message or parents changed)
. = clean commits (no changes to file tree)
Before After
-------------------------------------------
First modified commit | [FIRST_MODIFIED] | [FIRST_NEW]
Last dirty commit | [LAST_MODIFIED] | [LAST_NEW]
Changed files
-------------
Filename Before & After
----------------------------------------
weeklyRecommend.js | [FILE_HASH_BEFORE] ⇒ [FILE_HASH_AFTER]
In total, 26 object ids were changed. Full details are logged here:
C:\Users\User\Desktop\Project\bfg_cleaner\some_example_repo.git.bfg-report\2024-11-01\15-25-57
BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive
변경 전
변경 후
변경전 후 커밋 이력 비교(모든 커밋 sha값 바뀜)
cb71042 (HEAD -> main, origin/main, origin/HEAD) style(commands): change footer introuduce
e7edb8b fix(commands): thread key name -> a955361
6f3aeae refactor(command): change keyname and add created date -> 248c185
dd48fd2 refactor(command): add created date -> 9fca2e1
bfg로 clean 특정 구간부터 중복 커밋이 여러개 생겼다. rebase로 한 땀 한 땀 수정해보자
중복이 문제가 일어난 커밋은 bfg로 수정한 커밋이 있는 곳부터일어남
그리고 확인해보니 이전의 수정전 커밋과 수정 후 커밋이 둘다 있음.
즉 브랜치, 머지가 꼬이면서 기존의 커밋을 bfg 로 새로운 커밋들만 push되야하는데, 로컬의 환경과 클라우드 환경 둘다 하다보니 꼬여버리면서 클라우드 환경에서 남아있던 bfg 이전의 커밋들까지 push된 것 같음
rebase 인터렉티브하게 시작
git rebase -i --root
git rebase --abort
중복 커밋 안보임
머지 커밋까지 포함하기
git rebase -i --rebase-merges <start-commit>
vim ggVG, y
중복커밋 시작
중복 커밋 끝
중간중간 머지컨플릭트 해주면서
git rebase --continue 진행해주기
완료되면 main브랜치로 돌아오고 git log시 중복 커밋 삭제된거 확인 가능
그다음 중요한 git push --force 수행
클라우드 로컬환경의 브랜치를 원격의 리모트로 강제 교체
git fetch origin
git reset --hard origin/main