WTF!!!!
푸릇함이 사라진 나의 정원... 회색 콘크리트만 가득한 것 같다.
잔디가 전부 뽑혀 날아가버렸다.
최근 pull을 하지 않고 작업물을 변경하면서 conflict로 인해서 스트레스를 엄청나게 받고 있었다. 그래서 나는 pull을 강제로 해서 문제들을 해결해왔다.
하지만 알수 없는 이유로 pull을 강제로 해도 되지 않았고, 양쪽 작업물 사이에서 왔다 갔다 하는 와중에 결국 나는 clone을 해서 작업물 기록을 새로 업데이트 하지 않고 어떻게 한건지 모르겠는 신박한 방법으로 push를 했다.(아마도 --force를 한듯하다.) 정말 어떻게 했는지 기억이 나지 않는다. .git 파일을 삭제하고 초기화한건지 뭔지는 모르겠지만... 잔디가 갑자기 전부 뽑힌것을 보고 당황했다. 이전에 저장해놨던 작업물이라도 있지 않을까 해서 노트북과 데스크탑을 모두 뒤졌지만 찾을 수 없었고, 결국 log를 복구할수조차 없는 상황이 되었다.
만약에 지금 상황이 회사였다면 나는 어떻게 됐을까?
생각만해도 끔찍하다. 시말서 감일까? 아니면 잘리게될까? 휴... 정말 그 자리에 있는 것을 상상만해도 지옥같다. 어쨌든 내가 지금까지 열심히 심었던 잔디가 한순간에 뽑혀 없어진 것을 보니 정말 화가나고 이전 기록으로 롤백할수도 없으니 (그럴일은 없겠지만) 만약 작업에서 치명적인 무언가가 발견되었을 때 되돌아갈 수도 없으니까 문제가 생기면 일일히 수작업으로 변경해줘야하는 상황이 되어버렸다. 만약 팀 단위로 작업 중이었다면 나는 팀의 재산을 통째로 날린 사람이다. (무엇보다도 이전의 결과물이 없어져버렸다.)
소 잃고 외양간 고친다.
자기 전에 에디터만 업데이트 하고 자야지 했던 것이, git 문제를 이거 찾고 저거 찾고 하느라 벌써 새벽 3시다. 머리가 아프지만 분노 때문에 잠이 오지 않는다. 심장이 너무 뛴다. 어쩔수 없다. 이미 잔디를 전부 다 잃어버렸다. 하지만 git 사용법을 지금이라도 다시 익혀야한다. 그렇지 않으면 아마 팀 단위로 해야하는 작업에서 나는 재앙을 양산하는 고문관이 될지도 모른다.
git 사용법 다시 익히기
참고한 블로그 또는 튜토리얼
Lean Git Branching
좋은 git 커밋 메시지를 작성하기 위한 7가지 약속
나는 깃허브를 사용하기 때문에 원격 저장소를 처음 만들었을 때 부터 저장, 충돌 등의 상황을 정리해보려고한다.
새로운 내용의 작업을 해야할때는 고민하지 말고 branch 만들기
혼자 코딩을 하더라도 일단 새로운 작업을 할 때는 branch를 만들어서 새로운 내용을 작성하기로 했다. 협업 할 때 어떻게 하는지 정확하게 알 수는 없지만 이렇게 하는 편이 충돌을 피하는 가장 간편한 방법이 아닐까 싶다.
// work-editor라는 브랜치를 만든다.
$ git branch work-editor
// 브랜치 목록을 확인한다. 화면에서 wq를 입력하면 터미널로 나올 수 있다.
$ git branch
// work-editor 브랜치를 사용하여 작업다.
$ git checkout work-editor브랜치를 생성과 동시에 그 브랜치로 이동하는 방법은 checkout -b 명령어를 사용하는 것이다.
$ git checkout -b work-editor브랜치의 이름을 변경하고 싶다면 git branch -m 명령어를 사용해서 변경할 수 있다.
$ git branch -m [변경하려는 브랜치의 이전 브랜치 이름] [새로운 브랜치 이름]
ex)
$ git branch -m work-editor new-work-editor
$ git branch
// 브랜치 이름이 변경된 것을 확인 할 수 있다.새롭게 바뀐 브랜치를 원격 저장소에도 적용하고 싶다면
//새롭게 변경한 브랜치를 저장소에 push 한다.
$ git push origin 변경된 브랜치 이름
// 변경 전 이름을 원격 저장소에서 삭제한다.
$ git push origin :변경 전 브랜치 이름
새로운 브랜치로 작업이 아직 안끝났다.
아직 브랜치에서 해야할 것이 많고 깃 허브 저장소로 push를 해야할 때는 기존에 사용하던 명령어와 유사하다.
$ git add .
$ git commit -m "커밋할 내용"
$ git push origin work-editor새로운 branch를 push 하기 전에 git log를 살펴보면 현재 HEAD가 어디를 가리키고 있는지 볼 수 있다.
$ git log
commit <커밋 해시태그> (HEAD -> work-eidtor, origin/work-editor)
// q 또는 wq로 빠져나올 수 있다.HEAD가 work-editor를 가리키고 있다. push를 하면 origin/work-editor
새로운 코딩 작업이 끝났다 이제 main과 합쳐주고 싶다.
참고
Git Merge와 Rebase의 차이, 아름다운고 깔끔한 Git History 만들기.
[GIT] Merge vs Rebase 차이
git merge와 rebase의 차이: rebase의 이해
Git Rebase 활용하기
merge
만약 main branch에 work-eidtor 작업 내역을 merge하는 상황이라면 베이스가 되는 브랜치에서 병합을 실행하면 된다.
$ git checkout main
$ git merge work-eidtor
이렇게 실행하게 되면 두 가지 방법으로 병합이 되는데 fast-foward는 공통된 조상을 기준으로 두 브랜치가 병합된다. 3-way-merge의 경우는 merge를 실행할 때 병합하려는 두 브랜치에서 각각 따로 commit을 진행했을 때 공통된 조상이 사라진다. 그래서 새로운 commit으로 두 브랜치를 병합하게 된다. 이렇게 할 경우에 history가 매우 복잡해질 수 있다.
rebase
$ git checkout main
$ git merge work-eidtor만약에 3-way-merge의 경우에 rebase를 진행하게 되면 베이스가 되는 브랜치의 HEAD가 가리키는 곳을 기준으로 log가 정렬된다.
그럼 무조건 rebase??
글들을 살펴보면 무조건 rebase를 사용하는 것은 아니라고 한다. 왜냐하면 rebase는 깔끔하게 log를 남길 수 있지만 commit을 변경하기 때문이다. 그래서 master(또는 main)브랜치의 commit에 다른 브랜치를 rebase하는 경우 commit의 베이스가 변경되기 때문에 rebase를 main에 사용하지 말라고 하는 것 같다.
stash
참조
[Git] git stash 명령어 사용하기
git stash 사용법: 커밋하지 않고 변경사항 저장하는 방법
stash는 지금 내가 하고 있는 것을 임시로 저장하는 방법이고 commit 없이 나중에 다시 꺼내서 작업할 수 있다. 지금까지 나는 new-git-tutorial이라는 브랜치를 만들어서 이 글을 작성하고 있는데, branch를 바꿀 때마다 commit을 하였다. 하지만 아직 작업이 다 끝나지 않았는데 쓸데없이 commit을 한다는 생각이 들었다. 그럴때는 stash를 사용해서 해결하는 방법이 있다.
$ git stashstash를 하게 되면 스테이지 상태에 있는 파일과 그렇지 않은 파일 모두를 저장한다.
스테이지 상태란?
git add를 한 상태의 모든 파일
읽어보기 : Git 3가지 상태 정리
다시 branch로 돌아와서 stash됐던 파일을 apply 명령어를 붙여서 불러올 수 있다.
// 스테이징 된 파일은 불러오지 않는다.
$ git stash apply
// 스테이징 된 파일까지 전부 다 불러온다.
$ git stash apply --index다시 stash에 저장된 것을 불러오고 나면 stash에 저장되어있는 stash list가 자동으로 삭제되는 것은 아니다. 따라서 drop 명령어로 stash list를 삭제해주어야한다.
$ git stash drop글을 마무리하면서
잘 모르겠는 것을 안다고 착각하는 것만큼 위험한게 없다는 것을 배웠다. 이번 사건은 인재였다. 시간 낭비라고 생각될지라도 모르는 개념을 만나면 천천히 읽어보면서 개념을 익혀야겠다. 물론 모든 것을 마스터할 수는 없다. 하지만 기본기가 잘 닦여있다면 거기에 추가하는 것은 어렵지 않을 것 같다. 이번 실수와 같이 그냥 복붙만 하면 오히려 더 돌아가게 된고 내가 지금까지 한 것을 전부 망가뜨릴 수도 있다. 그동안 잔디 심는 즐거움이라도 있었는데 갑자기 내가 심었던 잔디들이 전부 사라진 것을 보니 마음이 허하다.
