fork 한 레포가 삭제됨, 나는 계속 작업할건데..?!

sarahsea·2021년 8월 24일
0
post-thumbnail

[1] 상황

상황 요약

내 원격저장소로 fork한 Repository,
원본 레포 관리자가 내 접근 권한을 삭제 -> 내 원격저장소의 해당 레포 삭제됨, 그렇다면 내가 작업한 파일들은 어떻게 되는 걸까?
다시 접근 권한을 얻는다면, 바로 push가 될까? fork를 또 해와야 하는걸까?

정확히 어떤 상황인가...

  1. 코드스테이츠의 매 스프린트(과제)마다 fork를 해서 내 원격 저장소에 가져오고,
    git clone으로 로컬에서 작업하고, 원격에 push 해둠 (가끔 push를 깜빡하고 하지 않은 경우도 있음 git status // modified:~ 상태)

  2. 기수이동을 하게 되면서, 코드스테이츠에서 나의 30기 권한을 박탈
    (정확한 매커니즘은 모르나, 그룹에서 날 삭제했을듯, 아마도 이 시점의 내 계정은 코드스테이츠 모든 레포에 접근 권한이 없는 "아무개")
    → has been deleted 메일 폭탄ㅎㅎ

    깃헙/나의계정 으로 달려감
    → Repositories(N)의 개수가 한자리수로 + 5~7월 잔디밭도 까맣게 죽음
    → 순간 이성을 잃음 🤯 (찬찬히 생각해 보면, 로컬파일을 지운 적이 없거늘,)
    '모든 기록이 날아갔다' 라고 인식됨(화전민도 아니고, 시커먼 잔디밭 임팩트가 한 몫;)

  3. 상황 이해를 위한 노력 (사실 당황타서 무지성 상태였음;;)

  • 아고라 검색_ 관련 내용 없음
  • 깃헙 docs 검색 & 구글링_ 내게 적용될 상황이 뭔지 잘 모르겠음 + 대부분의 경우는 개인레포를 삭제한 경우 복구에 대한 방법, 포크된 레포가 지워졌을 경우에 대한 예시가 잘 없음
  • 페어분들 문의 1:"저는 해당 섹션만 지워졌는데요?" 2:"아 저도 그랬어요"
  • 엔지니어님 문의:
    "깃헙 레포지토리가 삭제 되어 보이는 부분은 일시적인 현상,
    현재 31기 멤버로 소속되어 섹션1,2에 대한 레포 접근이 가능하다,
    PR이 아닌 개인 랩탑으로 다운을 받아두었거나,
    github 계정으로 Push 보냈다면 백업 되어있다
    개인계정에서도 레포를 포크 했었다면, 해당 로그를 확인 가능함"

→ 여기서 내가 헷갈린 부분은, 페어 한 분이 본인은 '해당섹션만 지워졌다'고 했기에 '섹션3만 지워져야 하는데 나만 1,2 다 지워진게 아닌가 하는 의심 스택++' &
엔지니어님의 "삭제 되어 보이는 건 일시적인 현상" 이라는 표현 이었는데,
마치 시간이 지나면 '삭제 되어 보인' 게 다시 돌아올 것 이라는 뜻처럼 느껴졌기 때문이다

하지만, 메일 내용도 분명 "지워졌다" 라고 되어있고,
Github Docs/ Working with forks /Deleted or changes visibility 여기서도 레포가 지워졌다는 것은 분명

엔제니어님의 솔류션에 따라 로컬 해당 폴더의 git log & git status를 확인하니,

  • case1: 내가 커밋한 로그가 잘 보임,
    status: Change not staged for commit: modified:~~
  • case2: 내가 커밋한 로그는 안 보이고, status: 상동
  • (case3: 아직 전체 레포를 다 확인하지는 못했다 ㅠ)

하지만, 다시 코드스테이츠 31기 권한을 얻은 나는, 동일한 레포에 대해 다시 접근이 가능 해짐

➡️ 결론, 내가 원하는 것은 예전 상태 복구

: 여기서 예전 상태란,
1. 내 계정에 들어가면, 이전에 작업했던 레포들의 갯수가 동일하게 뜬다 (현 8개 -> 예전 43개)
2. 과제를 다시 풀어보거나 변경사항이 있을 시, 충돌 없이 내 원격 저장소에 push가 가능하다
3. 이전에 커밋한 기록대로 잔디가 돌아온다(필수는 아니지만 되면 좋겠다..랄까)

[2] 해결 방법

before think solutions, what I confused

Q. fork한 레포가 지워진 뒤, 다시 fork를 한다면, 로컬의 해당 git 파일은 원격저장소의 레포를 동일한 레포로 인식하는가?
A_ ing🤔

Q. 지워진 레포 자체를 복구하는 방법은 없는가? (꼭 다시 fork를 해와야할까?)
A. YES, 내가 생성한 레포나, 내가 organization의 owner라면 가능하지만, 나의 경우에 원격저장소에 레포가 아예 삭제 된 것이므로.
// 개인이 생성했던 레포의 경우 세팅에서 휴지통처럼 복구 할 수 있다 90일 이내

가정 1: 새로 fork한 레포, 다시 clone

  • 새로 fork한 repo를 다시 clone, local에 가지고 있던 파일들 복붙하기
    • 성공률에는 가장 자신 있는 방법이자, 가장 스마트하지 못한 방법일거라고 생각
    • 하지만 이전에 커밋한 로그들은 사라진다는 단점

내가 원하는 상태 해결법이 아님, 실행 no

가정 2: 컴터가 시키는대로 한다, 기계는 옳다

git status
이후에 나오는 대로 add, commit 한 후,
평소처럼 git pull origin master 라고 하니,
레포가 없다고 해서, fork를 다시한 뒤, 다시 pull,
충돌 conflict!
충돌 수정 후 다시 add, commit

장: git 이 알려주니까 신뢰도 백프로,
단: 충돌 수정이 번거롭고, 충돌 보면 기분부터 별로잖아용?ㅋㅋ
=> 충돌 없이 깔꼼하게 해결하고 싶어짐

가정 3: rebase

  • 삭제된 레포를 origin으로 알고 있는 로컬 깃파일에게,
    새로 포크한 레포를 rebase 해준다?!

git rebase에 대한 이해 → 참고: 3.6 Git 브랜치 - Rebase 하기
(도식이 있어 이해하기 좋음)
실습 참고: 박준우님의 git rebase 이해하기

// 막간 git 명령어 메모
git stash  // commit하지 않고 임시로 잠깐 저장해놓기로 알고 있었는데,
git stash pop // 정작 다시 그걸 불러오는 명령어 깜빡;)

실행 결과: 레포 개수 복구(다시 포크했으니 당연) ✅
git log 유지 및 변경사항 push ✅
잔디 복구 ❌

comment: rebase를 공부하는 과정에서, 레포를 삭제하면 잔디 (contribution credit)는 사라진다고 공식문서에 나와있다 ㅠ따흑..

가정 4

가정3을 하고보니,

  • fetch만 하면 되는 거 아닌가?!
    -fetch가 뭐더라..
//리모트 저장소 확인하기
git remote -v  // 자주 쓰던 명령어
git remote show origin  // 알고보니 리모트 저장소의 구체적인 정보를 확인할 수 있다
//pull 은 fetch + merge
// 리모트를 추가하려면
git remote add <단축이름> <url>
// 리모트 저장소에서 데이터를 가져오려면 fetch
git fetch <remote>
// 그냥 쉽게 git pull 명령으로 리모트 저장소 브랜치에서 데이터를 가져올 뿐만 아니라 자동으로 로컬 브랜치와 Merge 시킬 수 있다

참고: git-scm.com-리모트 저장소

아 그러니까 pull 할수 있다면 이미 fetch , merge의 과정이 된 것이구나!
→ 그럼 origin을 재설정할 수도 있으려나? 있겠지? 꼬꼬무..ㅎㅎ

잔디복구에 대해

검색결과,
굳이 하자면 날짜를 돌려서 커밋을 다시 하는 등,
방법이 없는 것은 아니다
하지만 그렇게까지 해서 심는 잔디가 의미가 있을까 싶기도허고,,
덕분에 깃헙 사용에 대해 평소보다 찐하게 찾아보는 의미 있는 시간을 가진 것으로 만족, 다만 그렇게 편법같은(?)방법이 아닌 다른 방법이 더 있는지(분명히 내 커밋 로그는 살아있으니까?) 찾아볼 예정

+ 잔디체크 public repo 잔디체크

[3] 결론 및 배운 점

배운 것

  • git log 명령어는 최신 로그 몇개만 나오기 때문에, fork한 레포의 경우, 내가 커밋을하고 (두달전?) 원본레포가 최근에 업데이트가 여러개 있었다면, 내 로그가 보이지 않을 수 있다 // case2 해결!
  • fork한 레포가 지워질 경우, 당연히 다시 fork는 언제든 가능하다 (공개된 경우, 접근권한이 있는경우) 단, 잔디가 다 사라지고, PR을 하지 않았다면, 내 로컬까지 다 지운 경우, 작업한게 어디에도 남지 않을 수 있다
    // 레포 지우기 전, 잔디가 중요하다면, 잘 생각해보기
  • git pull 과 fetch, 원격저장소와 내 로컬의 관계, 알고 있다고 생각했는데, 아니었더라ㅎ => git docs 에 참 잘 나와있고, 제일 설명도 잘 되어있다, 뭐든지 공식문서가 짱이다! 방대한 양에 쫄지 말자!

새로운 의문❓

  • 일단 어찌저찌 해결이 되는 방법 하나는 찾았는데, 이것보다 더 세련된 방법이 있는 것은 아닐까 하는 꼬꼬무 (이게 "정답"인지 확신을 갖고 싶음이랄까)
  • 여러개 레포에 대해서 동일 작업을 해줘야 하는데, 이렇게 내 원격저장소와 로컬을 이어주는 작업을 배포자동화처럼 한번에 프로그래밍 할수는 없을까?
  • 처음 배울때부터 shell 을 이용해서 배우다 보니 GUI 프로그램을 사용할 생각을 안해봤는데, 관계를 이해하기 위해서 브랜치의 상태가 눈으로 보여지는
    sourcetree같은 프로그램을 사용해 봐야겠다 -> 좀 더 간편한 방법이 있는지
  • 검색하다보니, 원본 레포의 업데이트 사항이 더이상 나와 상관없는 경우,
    레포를 fork 하지않고 아예 복사 하는 개념이 있던데, 내 경우 복사를 하면 어떤 문제가 있을까? => 복사하게 되면 레포가 내 소유니까 이렇게 지워진걸 일일히 복구해야 하는 일이 없지 않을까 하는 의문 => 물론 기수이동을 하게되면 해당섹션 레포를 다 지우는게 규칙이라 따르지 않을 생각은 없지만, 왜 이전 섹션까지 다 지워야하는지..ㅠ 고것은 어쩔수 없는 그룹 멤버 관리 구조 때문인거 같은데..

마치며

검색을 해가면서, 정리하는 겸, 기록으로 남길 겸 벨로깅을 해보았는데,
아무래도 알아가면서 쓰는 내용이다 보니 틀린 부분이 있을 수 있습니다.. (댓글제보 환영)
새로운 의문들은 앞으로 더 학습할 계획!! 재미지다~

profile
생각하는 사람

0개의 댓글