삭제한 옛날 branch 살리기

모르고 삭제해버린 옛날 브랜치 되살리기

issue 작업을 끝내고 PR날리고 dev브랜치와 issue737브랜치를 master로 병합 후 깔끔하게 삭제했다. 그 뒤로 수많은 커밋을 master로 날리고 새로운 issue641브랜치 생성하여 커밋을 날렸다. 날렸는데
앞으로 일어날 일에 대해서는 전혀 알지못한채… 깔끔 IS THE BEST라고 생각하며…

하지만 PR날린게 conflicts 나면서 다시 그 브랜치가 필요해졌다!!!
망함.

심장부여잡고 폭풍검색한 끝에 reflog란 명령어가 있다는 사실을 알았다.

현재 내 상황

1. master브랜치에서 dev브랜치를 생성
2. dev브랜치 커밋날리고 master브랜치로 병합
3. dev브랜치 삭제
4. master브랜치에서 issue737브랜치 생성
5. issue737브랜치 커밋날리고 master브랜치로 병합
6. issue737브랜치 삭제
7. master브랜치에서 issue641브랜치 생성
8. issue641브랜치 커밋날림. (병합안함)

이 상황에서 나는 dev브랜치와 issue737브랜치를 살려야 한다.
그것도 각 브랜치의 커밋과 함께!!
할 수 있을까?

reflog란?

브랜치나 태그의 모든 변경사항을 기록한다.
참고링크 : reflog기초

내 상황을 reflog를 통해 들여다보자.

$ git reflog
14e5ed2 (HEAD -> issue641) HEAD@{0}: commit: 이슈641commit
0251dd3 (master) HEAD@{1}: checkout: moving from master to issue641
0251dd3 (master) HEAD@{2}: merge issue737: Fast-forward
f04a0fc HEAD@{3}: checkout: moving from issue737 to master
0251dd3 (master) HEAD@{4}: commit: 이슈737 commit
f04a0fc HEAD@{5}: checkout: moving from master to issue737
f04a0fc HEAD@{6}: merge dev: Fast-forward
fee6895 (origin/master, origin/HEAD) HEAD@{7}: checkout: moving from dev to master
f04a0fc HEAD@{8}: commit: dev commit
fee6895 (origin/master, origin/HEAD) HEAD@{9}: checkout: moving from master to dev
fee6895 (origin/master, origin/HEAD) HEAD@{10}: reset: moving to HEAD~1
405f8cd HEAD@{11}: commit: dev 첫번째커밋
fee6895 (origin/master, origin/HEAD) HEAD@{12}: clone: from https://github.com/sowon-dev/conflict-resolve.git

1. HEAD@{12} : 레포 클론해옴
   • HEAD@{10}과 HEAD@{11}은 그냥 무시해도 됨.dev에서 커밋해야하는데 master에서 커밋해버려서 커밋삭제한 로그임ㅋㅋㅋ
2. HEAD@{9} : dev브랜치생성후 dev브랜치로 체크아웃
3. HEAD@{8} : dev브랜치에서 커밋날림
4. HEAD@{7} : dev브랜치에서 master브랜치로 체크아웃
5. HEAD@{6} : master브랜치로 dev브랜치 병합 후 삭제
6. HEAD@{5} : master브랜치에서 issue737브랜치 생성 후 체크아웃
7. HEAD@{4} : issue737브랜치에서 커밋날림
8. HEAD@{3} : master브랜치로 체크아웃
9. HEAD@{2} : master브랜치로 issue737브랜치 병합 후 삭제
10. HEAD@{1} : master브랜치에서 issue641브랜치 생성 후 체크아웃
11. HEAD@{0} : issue641브랜치에서 커밋날림

여기서 dev와 issue737을 각각 커밋과 함께 살려야한다.

해결순서

1. git branch : 현재 내가 가지고 있는 브랜치 확인하기
2. git reflog : HEAD가 가리키는 커밋이 바뀔 때마다 Git은 자동으로 그 커밋이 무엇인지 기록한다. 새로 커밋하거나 브랜치를 바꾸면 Reflog도 늘어난다. 참고링크
3. 삭제한 브랜치 찾기
4. git checkout -b [deleted-branchName] HEAD@{number} : 삭제한 브랜치 커밋 되돌리기
   • 그런데 삭제한 브랜치에 대해 수많은 로그가 있는데 그 중 어떤 로그를 되돌려야할까??
   • 실험결과 ** merge 브랜치명: Fast-forward ** 로그를 되돌려야 해당 브랜치의 커밋까지 살아난다!!

//기본값
$ git branch # 내가 가지고 있는 브랜치 확인하기
$ git reflog 
$ git checkout -b [deleted-branchName] HEAD@{number}

//예시
$ git branch
* issue641
  master
  
$ git checkout master
0251dd3 (HEAD -> master) HEAD@{0}: checkout: moving from issue641 to master
14e5ed2 (issue641) HEAD@{1}: commit: 이슈641commit
0251dd3 (HEAD -> master) HEAD@{2}: checkout: moving from master to issue641
0251dd3 (HEAD -> master) HEAD@{3}: merge issue737: Fast-forward
f04a0fc HEAD@{4}: checkout: moving from issue737 to master
0251dd3 (HEAD -> master) HEAD@{5}: commit: 이슈737 commit
f04a0fc HEAD@{6}: checkout: moving from master to issue737
f04a0fc HEAD@{7}: merge dev: Fast-forward
fee6895 (origin/master, origin/HEAD) HEAD@{8}: checkout: moving from dev to master
f04a0fc HEAD@{9}: commit: dev commit
fee6895 (origin/master, origin/HEAD) HEAD@{10}: checkout: moving from master to dev
fee6895 (origin/master, origin/HEAD) HEAD@{11}: reset: moving to HEAD~1
405f8cd HEAD@{12}: commit: dev 첫번째커밋
fee6895 (origin/master, origin/HEAD) HEAD@{13}: clone: from https://github.com/sowon-dev/conflict-resolve.git

실험 : 수많은 로그중에 어떤 로그를 써야 내가 원하는대로 각 브랜치의 커밋까지 그대로 살아날까?

• 첫번째 시도 : HEAD@{8}: checkout: moving from dev to master

$ git checkout -b dev HEAD@{8}

$ git branch
* dev
  issue641
  master

$ code .

• 첫번째 시도 결과 :
  • dev브랜치에서 code .로 열였을때 내가 작성한 커밋이 반영되어있지않았다.
  • master브랜치 code .로 열였을때 내가 작성한 issue737까지 포함된 커밋이 그대로 보존되어있었다.
  • 결론 : master브랜치의 상태에 변화를 주지않고 dev브랜치만 살아나는 데 dev에서 커밋한 내용은 없음.

• 두번째 시도 : HEAD@{3}: merge issue737: Fast-forward

$ git checkout -b issue737 HEAD@{3}
$ git branch
  dev
  issue641
  issue7
* issue737
  master
$ code .

• 두번째 시도 결과 :

  • issue737브랜치에서 code .로 열였을때 내가 작성한 커밋이 그대로 보존되어있었다.
  • master브랜치 code .로 열였을때 내가 작성한 issue737까지 포함된 커밋이 그대로 보존되어있었다.
  • 결론 : master브랜치의 상태에 변화를 주지않고 issue737브랜치만 살아난다! 되살리기 성공!

• 실험 결론 : ** merge 브랜치명: Fast-forward **를 되돌려야 해당 브랜치의 커밋까지 살아난다!!

실무에선 추가로 생성한 branch는 보통 언제 삭제할까?

깔끔한게 좋다며 괜히 브랜치 삭제해서 진짜 큰일 날뻔했다.
도대체 새로 생성한 브랜치는 언제 삭제하는 지 궁금해져서 보라님께 물어봤다.
아래 두가지 경우에서 삭제한다고 한다.

• PR날려서 머지되면 삭제함.
• 어차피 회사가면 jenkins라는 툴로 브랜치관리함.