내 원격저장소로 fork한 Repository,
원본 레포 관리자가 내 접근 권한을 삭제 -> 내 원격저장소의 해당 레포 삭제됨, 그렇다면 내가 작업한 파일들은 어떻게 되는 걸까?
다시 접근 권한을 얻는다면, 바로 push가 될까? fork를 또 해와야 하는걸까?
정확히 어떤 상황인가...
코드스테이츠의 매 스프린트(과제)마다 fork를 해서 내 원격 저장소에 가져오고,
git clone으로 로컬에서 작업하고, 원격에 push 해둠 (가끔 push를 깜빡하고 하지 않은 경우도 있음 git status // modified:~
상태)
기수이동을 하게 되면서, 코드스테이츠에서 나의 30기 권한을 박탈
(정확한 매커니즘은 모르나, 그룹에서 날 삭제했을듯, 아마도 이 시점의 내 계정은 코드스테이츠 모든 레포에 접근 권한이 없는 "아무개")
→ has been deleted 메일 폭탄ㅎㅎ
깃헙/나의계정 으로 달려감
→ Repositories(N)의 개수가 한자리수로 + 5~7월 잔디밭도 까맣게 죽음
→ 순간 이성을 잃음 🤯 (찬찬히 생각해 보면, 로컬파일을 지운 적이 없거늘,)
'모든 기록이 날아갔다' 라고 인식됨(화전민도 아니고, 시커먼 잔디밭 임팩트가 한 몫;)
상황 이해를 위한 노력 (사실 당황타서 무지성 상태였음;;)
→ 여기서 내가 헷갈린 부분은, 페어 한 분이 본인은 '해당섹션만 지워졌다'고 했기에 '섹션3만 지워져야 하는데 나만 1,2 다 지워진게 아닌가 하는 의심 스택++' &
엔지니어님의 "삭제 되어 보이는 건 일시적인 현상" 이라는 표현 이었는데,
마치 시간이 지나면 '삭제 되어 보인' 게 다시 돌아올 것 이라는 뜻처럼 느껴졌기 때문이다
하지만, 메일 내용도 분명 "지워졌다" 라고 되어있고,
Github Docs/ Working with forks /Deleted or changes visibility
여기서도 레포가 지워졌다는 것은 분명
엔제니어님의 솔류션에 따라 로컬 해당 폴더의 git log & git status
를 확인하니,
status: Change not staged for commit: modified:~~
하지만, 다시 코드스테이츠 31기 권한을 얻은 나는, 동일한 레포에 대해 다시 접근이 가능 해짐
: 여기서 예전 상태란,
1. 내 계정에 들어가면, 이전에 작업했던 레포들의 갯수가 동일하게 뜬다 (현 8개 -> 예전 43개)
2. 과제를 다시 풀어보거나 변경사항이 있을 시, 충돌 없이 내 원격 저장소에 push가 가능하다
3. 이전에 커밋한 기록대로 잔디가 돌아온다(필수는 아니지만 되면 좋겠다..랄까)
Q. fork한 레포가 지워진 뒤, 다시 fork를 한다면, 로컬의 해당 git 파일은 원격저장소의 레포를 동일한 레포로 인식하는가?
A_ ing🤔
Q. 지워진 레포 자체를 복구하는 방법은 없는가? (꼭 다시 fork를 해와야할까?)
A. YES, 내가 생성한 레포나, 내가 organization의 owner라면 가능하지만, 나의 경우에 원격저장소에 레포가 아예 삭제 된 것이므로.
// 개인이 생성했던 레포의 경우 세팅에서 휴지통처럼 복구 할 수 있다 90일 이내
내가 원하는 상태 해결법이 아님, 실행 no
git status
이후에 나오는 대로 add, commit 한 후,
평소처럼 git pull origin master
라고 하니,
레포가 없다고 해서, fork를 다시한 뒤, 다시 pull,
충돌 conflict!
충돌 수정 후 다시 add, commit
장: git 이 알려주니까 신뢰도 백프로,
단: 충돌 수정이 번거롭고, 충돌 보면 기분부터 별로잖아용?ㅋㅋ
=> 충돌 없이 깔꼼하게 해결하고 싶어짐
git rebase
에 대한 이해 → 참고: 3.6 Git 브랜치 - Rebase 하기
(도식이 있어 이해하기 좋음)
실습 참고: 박준우님의 git rebase 이해하기
// 막간 git 명령어 메모
git stash // commit하지 않고 임시로 잠깐 저장해놓기로 알고 있었는데,
git stash pop // 정작 다시 그걸 불러오는 명령어 깜빡;)
실행 결과: 레포 개수 복구(다시 포크했으니 당연) ✅
git log 유지 및 변경사항 push ✅
잔디 복구 ❌
comment: rebase를 공부하는 과정에서, 레포를 삭제하면 잔디 (contribution credit)는 사라진다고 공식문서에 나와있다 ㅠ따흑..
가정3을 하고보니,
//리모트 저장소 확인하기
git remote -v // 자주 쓰던 명령어
git remote show origin // 알고보니 리모트 저장소의 구체적인 정보를 확인할 수 있다
//pull 은 fetch + merge
// 리모트를 추가하려면
git remote add <단축이름> <url>
// 리모트 저장소에서 데이터를 가져오려면 fetch
git fetch <remote>
// 그냥 쉽게 git pull 명령으로 리모트 저장소 브랜치에서 데이터를 가져올 뿐만 아니라 자동으로 로컬 브랜치와 Merge 시킬 수 있다
아 그러니까 pull 할수 있다면 이미 fetch , merge의 과정이 된 것이구나!
→ 그럼 origin을 재설정할 수도 있으려나? 있겠지? 꼬꼬무..ㅎㅎ
검색결과,
굳이 하자면 날짜를 돌려서 커밋을 다시 하는 등,
방법이 없는 것은 아니다
하지만 그렇게까지 해서 심는 잔디가 의미가 있을까 싶기도허고,,
덕분에 깃헙 사용에 대해 평소보다 찐하게 찾아보는 의미 있는 시간을 가진 것으로 만족, 다만 그렇게 편법같은(?)방법이 아닌 다른 방법이 더 있는지(분명히 내 커밋 로그는 살아있으니까?) 찾아볼 예정
+ 잔디체크 public repo 잔디체크
git log
명령어는 최신 로그 몇개만 나오기 때문에, fork한 레포의 경우, 내가 커밋을하고 (두달전?) 원본레포가 최근에 업데이트가 여러개 있었다면, 내 로그가 보이지 않을 수 있다 // case2 해결!검색을 해가면서, 정리하는 겸, 기록으로 남길 겸 벨로깅을 해보았는데,
아무래도 알아가면서 쓰는 내용이다 보니 틀린 부분이 있을 수 있습니다.. (댓글제보 환영)
새로운 의문들은 앞으로 더 학습할 계획!! 재미지다~