D'story

임시보관함 1개로 버티기

• 이 작업, 저 작업 왔다 갔다 진행하고 있을 때라면 더더욱 진행 상황을 보관할 곳이 필요하다. 그럴 때 쓰는 명령어가 `git stash`이다. 아직 커밋을 하기는 좀 부족한데 당장 다른 것과 섞이게 하고 싶지는 않을 경우에, 간단하게 `git stash`로 보관하고, `git stash apply`로 가져올 수 있다.
• 물론 stash의 인덱스를 활용해서 골라 가져오는 방법도 있지만, 그게 아니고서는 한 번에 하나만 보관해야 한다는 단점이 있었다. 처음부터 그 단점을 느낀 건 아니었지만, 이 명령어를 하도 사용하다 보니 가끔 아쉬웠다. A라는 작업에서 이미 `git stash`를 한 번 썼는데 B라는 작업으로 잠깐 옮겨 가서 또 다른 일을 벌이던 중에, 다시 A로 돌아가야 할 일이 생긴다거나. 한 번에 한 가지 일을 진득하게 해서 끝내버린다면 필요 없을 일이겠지만...(머쓱)

임시보관함 여러 개 쓰기

• `git stash`를 하는 순간부터 내가 이 stash에 이름을 정해주고 싶을 때는 이렇게 해 주면 된다. 예를 들어 stash_name이라는 이름을 넣어주고 싶다고 하면 이런 모양새가 될 것이다.

git stash push -m stash_name

• 나중에 이 stash를 가져올 때는 이렇게 가져오면 된다.

git stash apply stash^{/stash_name}

• 그런데 여기서 만약 stash에 띄어쓰기를 포함한 이름을 정해줬다면, 따옴표로 한 번 묶어줘야 한다. 예를 들면 다음과 같다.

git stash push -m 'I want to push this sentence'

• 가져올 때도 마찬가지이다.

git stash apply stash^{/'I want to push this sentence'}

오늘은

• 너무 오랫동안 방치되어 있던 블로그를 다시 살려내 봐야겠는데, 뭐부터 시작하면 좋을지 아주 짧게 고민하다가 그냥 두서없이 간단하게 시작하기로 했다. 시작이 반이니까
• 그런데 놀랍게도 나조차도 간만에 찾은 내 블로그에는 꾸준히도 방문자가 유입되고 있었다. 의아하기도 하고 한편으로는 부끄럽다.
• 아무튼 오늘은 시간을 되돌려 내 과거를 살짝 고칠 수 있는 방법을 소개하겠다. 별 거 아닐 수 있지만, 나로서는 자주 활용하지는 않다 보니 필요할 때마다 잊어버려서 자꾸 다시 검색하곤 하는.. 그래서 블로그에 짧게나마 남기면 나한테 좋을 내용이다.

한참 지난 커밋 수정하기

• 방금 작성한 커밋을 수정하는 것은 밥 먹듯이 있는 일이라 별로 두렵지 않은데, 가아아끔씩 지지난, 혹은 지지지지지난 커밋에서 뭔가 잘못되었다는 것을 불현듯 깨닫는 경우가 있다. 지금 생각해 보면 그건 도대체 어떻게 깨달은 걸까, 심지어 그렇게 늦게.. 그렇다고 그 뒤의 커밋들은 돌이키고 싶지 않은데, 나 분명 이거 해결하는 방법 아는데, 그 방법을 기억을 못 해서 결국 다시 구글링하게 된다. 블로그에 쓰면 그래도 적은 가능성으로나마 기억에 남을 수도 있지 않을까..?

1. 고치고 싶은 commit hash를 알아낸 후, 터미널에 다음과 같이 입력한다.

git rebase --interactive [commit hash]^​

2. vim을 이용하여, 터미널에 나타난 해당 commit의 `pick`을 `edit`으로 바꿔준 후 저장, 종료한다.
3. commit을 수정한다.
4. 수정이 끝났다면, 터미널에 다음과 같이 입력한다.

git rebase --continue​

• vim에도 git에도 익숙하지 않던 시절, 세훈님이 이 interactive 옵션을 사용하시는 걸 처음 봤었는데 그땐 왜 이걸 편하다고 말씀하시는 건지 이해할 수가 없었다. 지금은 나도 편하다. 그런데 이유는 아직도 모른다.

지금까지 한 일(기억 나는 대로)

• 구글 로그인은 API 변경 이후로, 가장 최신 버전을 적용하면 버튼에 커스텀 디자인을 입힐 수 없다. API 하나하나 분해(ㅋㅋㅋ)해서 입혀 보려고도 해봤으나 쉽지 않았다. 그래서 커스텀 디자인을 넣을 수 있다는 라이브러리를 찾아서 그 코드를 뜯어 보았지만 내가 라이브러리 없이 했을 때 맞닥뜨리는 문제를 똑같이 만나게 되어서 라이브러리도 별 수 없구나 하는 것을 배웠다. 물론 문제가 다른 데 있을 수도 있지만
• 구글을 가지고 이렇게나 헤맨 것치고 페이스북 로그인은 붙이기 쉬웠다. 반나절 만에 기능을 작동시킬 수 있었고, 커스텀 디자인도 물론 페이스북의 디자인 가이드를 따르긴 해야겠지만 기술적으로는 어떤 디자인이든지(심지어는 디폴트 버튼 그 회색 그것마저도...) 적용할 수 있었다. 하지만 지난 4월쯤? 페이스북은 한 번 붙이려다가 실패를 맛본 경험이 있었는데, 그건 페이스북 API가 까다로워서라기보다는 페이스북 API는 구글과 달리 테스트조차도 무조건 https 환경에서만 가능한데, 그땐 로컬호스트를 https로 돌리는 방법을 제대로 실행하지 못했기 때문이었다. 저번에 영봉님을 통해 알게 된 caddy를 이용해서 의외로 손쉽게 이 부분을 해결하고 나니 나머지 문제는 일사천리로 해결되었다.
• 요즘은 SSO 릴리즈 일정이 잡힌 후 개발 속도를 내고 있는 주간이어서 승진님이 만들어 두신 지라 카드 작업을 하고 있다. 그 와중에 구글 로그인과 관련해서 현지 팀과 계속해서 얘기를 할 일이 생겨서 이제까지 안 쓰던 영어를 어제부터 잔뜩 쓰려니 골이 아프다. 인도네시아어 번역이 누락된 부분이라든지, 구글 로그인 버튼 자체에 언어 설정을 적용하는 것이라든지, 어쨌든 브랜치를 하나 따서 관련된 작업을 하다가 연락이 뜸한 시점에는 또 다른 카드의 작업을 하는 식으로 진행하고 있었다.
• 그 다른 카드의 작업이 마무리되어서 push를 하기 전에 git log를 한 번 확인해 봤는데, 브랜치를 새로 안 따고 구글 브랜치에 그대로 작업한 것을 깨달았다. 터미널에서 브랜치 이름 그렇게 봐 놓고도 몰랐다니 😞
• 그래서 이번에 정확히 어떨 때 사용하라는 건지 와 닿지 않았던 git cherry-pick을 처음 써 보게 되었다.

오늘 배운 것

# branch A에서 branch B로 옮기고 싶다면

# branch A에서 옮기고 싶은 commit의 hash를 적어둔다
git log

# 그리고 branch B로 바꾼다
git checkout [branch B]

# commit이 하나인 경우
git cherry-pick [hash]
# commit이 복수인 경우
git cherry-pick [hash0] [hash1] [hash2]
# 어느 범위의 commit을 통째로 옮기고 싶은 경우
git cherry-pick [older hash]^..[newer hash]

git commit

오늘은

• 다이얼로그 작업은 아직도 끝나지 않았다. 깃 컨플릭인데 컨플릭만 해결한다고 사라지지 않는 어떤 문제가 생겨서 끙끙대다 어찌어찌 간신히 처리 완료한 줄 알았더니 아니었고...
• 내가 푸시한 깃을 풀 받은 승규님이 화면 공유로 확인시켜 주시는데 '내가 작업한 게 안 올라감 + 무슨 이유에선지 로컬에만 남아 있음' 상태여서 적잖이 당황. 내가 손을 댄 파일이 애초에 몇 개 없었기 때문에 일단 전부 스테이지에서 내린 후 stash 해놓고 작업하던 로컬 브랜치 삭제하고 아까 푸시한 브랜치 다시 풀 받아서 git stash apply로 겨우 살렸다. 
• 그러고 나니 뭐 많은 걸 한 게 아닌데도 그동안 차곡차곡 쌓여 왔던 온갖 생각이 한꺼번에 몰려왔다. 모르는 게 너무 많고, 아는 건 제대로 못 쓰고, 사실 저 바깥에 뭐가 있는지도 잘 모르고, 알려면 알 수 있고 보려면 볼 수 있는데 왜 항상 뭔가 부족한 상태에서 무작정 나아가려고만 하는 거지.
• 구멍이 많은데 그걸 메우기보다 일단 구멍을 피해서 가기만 하는 게 과연 상책일까. 구멍을 메우는 행동 자체가 당장에는 시간을 많이 쓸 것 같아도 어쩌면 결과적으로는 목적지까지 나를 빠르게 안내할 지도 모를 일이고, 설령 그 순간이 당장 지금이 아닐지라도 이게 쌓이고 쌓이면 나중에 구멍이 하나라도 적은 길을 가게 될 수도 있다.
• 앞으로 아무리 열심히 나아가려 한들 그 속도에 향상이 없다면, 반대의 경우에 비해서는 제자리걸음을 하고 있는 거나 마찬가지 아닌가.

오늘 한 일

• 스크럼 끝나고 나서 한참을 기억 저편에 묻어두었던 깃훅에 대한 카드를 케이님이 다시 상기시켜 주셨다. 나 너무 부지런하지 못하다..😢  기억을 다시 되돌리기 위해 빠르게 빠르게 husky와 git hook pre-commit 문서를 펼쳐 놓고 스크립트를 짜 보려고 하며 오전 시간을 보냈다.
• 그리고 오후에는 스프린트 미팅 - 승규님과의 페어 작업을 앞두고 사전 허들 - 셀러그로스 retrospective까지 해서 정신이 없었다ㅋㅋ.. 하루 웬종일 머릿속에 정보가 쏟아져 들어오는 느낌이었다. 물론 그거 다 흡수했다고는 안 했음
• 스프린트 미팅에서는 SSO와 다른 서비스들과의 관계를 시각적으로 보여달라는 소연님의 말에 승진님이 관계도를 그리기 시작하셨고... 미팅은 1시간을 채웠다...
• 카드가 나왔고 작업 estimation도 정했으니 승규님과는 내일부터 페어 프로그래밍을 진행하기로 했다. 일단 하기로 한 거고, 혹시 또  이런 프론트 작업에 페어 방식이 맞지 않는다면 작업 방식을 아예 바꿀 수도 있다. 드라이버는 페어 프로그래밍에 익숙한 승규님부터 시작하지만 나는 어떤 식으로 작업을 하는 건지 전혀 모르는 상태라 걱정 반 기대 반인 상태다.
• retrospective는 처음 참여해 봤는데 너무 재미있었다. 나는 거의 한 마디도 안 하고 참관만 했지만 재미있었다. 혹시 그래서 더 재미있었을까..!? 다음 번에는 나도 조금 더 주도적으로 참여할 수 있길.

오늘 배운 것

• 어제 썼듯이, 어제까지 작업한 모달, 그 모달에 이메일을 입력하면 비밀번호 초기화 페이지 링크 받는 것까지 확인해서 pr을 올렸다. 사실 작업 내용 자체는 별 게 없긴 했는데, 생각지도 못했던 부분에서 리뷰를 받았다. 타입스크립트 변수에 대한 타입 선언과 타입 추론 때문이었는데, 어차피 ""와 같이 값의 타입이 string이라는 걸 추론할 수 있는 변수인데 굳이 타입 선언이 들어갈 필요가 없다는 내용이었다. 타입스크립트니까 타입을 명시해줘야겠다고만 생각했을 뿐, 추론은 생각해 본 적이 없었다. 아래 링크에서 타입 추론 부분만 읽어 보았다. 머리에 들어올 것 같을 때 나머지도 마저 읽어봐야겠다.

오늘 한 일

• SSO 쪽에서는 특별히 당장 배정된 작업은 아직 없다. 대신 약 3개월 가량의 작업 시간 여유가 생겼다고 한다. 시간이 자꾸 늘어나는 것 같은 건 기분 탓일까!?
• 하지만 그렇게 되면서 토코톡 로그인, 회원가입 페이지 UI 변경을 진행하게 되었다. 승규님과 함께 피그마 디자인을 보면서, 솔직히 얼마나 걸릴지 모르겠지만 일단 1주일 정도 작업 기간으로 잡고 시작하기로 했다. 예전에 승규님이 한 번 언급했던 것처럼, 이번에 드디어 카드가 할당되고 나면 페어로 작업하기로 했는데 페어 프로그래밍이 어떤 식으로 이루어지는지 전혀 모르는 나로서는 걱정이 앞선다. 대략적인 흐름 정도만 대강 공유하고 일단 카드를 기다리기로...
• 그동안 나는 지난 번까지 틀만 겨우 작업한 모달에 추가 작업을 했다. 모달에 이메일 주소를 입력하면 그 주소를 백엔드에 보내고, 보낸 후에는 확인 모달을 띄웠다. 그리고 해당 이메일 주소로 비밀번호 초기화를 안내하는 링크가 담긴 메일이 오는 것까지 확인했다. 하지만 아직 링크 타고 넘어간 페이지에는 아무것도 없다. 디자인도 나온 건 없는 듯...?
• 그리고 다행히도, 저번 주에 나의 무지함으로 인해 8일이나 늦게 시작된 QA는 다른 추가적인 문제 없이 넘어간 듯하다.

오늘 배운 것

• git add는 보통 git add . 로 변경 파일 전체를 스테이지에 올리지 않고 골라서 진행하더라도 어쨌든 파일 단위로 처리를 하는 명령어이다. 만약 파일 안에서도 라인별로 따로 스테이지에 올리고 싶다면 git add -p를 이용하면 된다. 그러면 터미널에 변경 사항이 찍히고, Stage this hunk? 하면서 어떻게 처리할 건지 묻는다. [y: 스테이지에 올린다 / n: 올리지 않는다 / q: 이 hunk 포함 나머지를 올리지 않고 끝낸다 / s: 이 hunk도 한 번 더 나눈다] 다른 명령어들은 아래 링크 참고!

오늘 한 일

• 어제 올린 pr은 approved 되긴 했는데 추가 작업이 필요한 상황이었다. 아침 스크럼 때 상황을 말씀 드리고 중간에 한 번 끊어서 머지를 해야 하는지 아니면 계속 작업을 하고 나서 완결(이라는 게 애초에 가능한지는...) 후에 한번에 머지를 해야 하는지를 여쭤보았다. 아직 배포 중인 서비스는 아니므로 한 번 끊고 가는 걸로 결론. 
• 늦어도 내일까지는 끝내야 월요일부터 QA 팀에서 테스트할 수 있는데, 간단한 작업만 남아서 다행이라고 말씀하신 소연님께 나는 그저 웃어드렸다...😅  그...래야 할 텐데 말이죠
• pr은 여느 때와 같이 머지했는데, 머지한 SSO 브랜치를 다시 pr을 날려서 메인에 머지해야 했다. 이론적으로는 알겠는데 메인 브랜치라고 하니까 알던 대로 하면 왠지 큰일날 것만 같고 내가 알던 그 pr 화면이 그 화면이 아닌 것 같고 막...
• 그리고 메인 브랜치에는 git squash를 해야 했다. 메인에 머지할 땐 혼자 작업했으면 squash, 여럿이면 merge. 찾아보니 squash란 커밋 여러 개를 하나로 묶는 작업인데, 그런 명령어가 있는 건 아니었고 일종의 옵션이다. cli로 할 필요는 없었고 깃헙 pr 화면에 버튼이 있었다. 평소엔 고민 없이 그냥 누르던 Merge pull request 버튼의 옵션 중에 Squash and Merge를 선택하면 된다. 그러면 description을 새로 입력하는 창이 나오는데 디폴트 값으로 그동안 했던 커밋 메시지들이 전부 나온다. 지울 건 지우고 남길 건 남겨서 정리하고 진행하면 된다. 
• 스몰톡 인터뷰...를 오늘 진행했는데 우리 조가 선정한 인터뷰 대상자는 TVA팀의 희순님이었다. 인터뷰 마감 날짜가 다가와서 하루 이틀 사이 일정을 잡고 질문 리스트 작성해서 희순님께 미리 전달하고 인터뷰를 했다.
• 줌에서 녹화 테스트를 한 번 해보고 나서 시작했는데, 예상했던 것보다 인터뷰 시간이 길어지면서 무료 회의 시간인 40분이 되어버려서 방이 터져버렸다. 문제는, 그 전에 인터뷰 및 녹화는 무사히 마쳤지만 줌 시스템상 녹화를 하면 후처리 과정이 있어야 하는데 이건 회의실이 정상적으로 종료됐을 때나 그렇단다. 회의를 사람이 직접 종료하고 나야 컨버팅이 시작되고, 그 후 영상 파일로 남는 데까지도 시간이 조금 걸린다는 것 같았다. 여기저기 찾아보니 30분 정도 녹화하면 컨버팅 시간만 약 10분 정도..? 어디를 찾아봐도 파일이나 녹화 기록이 제대로 남은 곳이 없었다. 심지어 이런 식으로 날린 녹화 파일은 다시 찾을 수가 없단다ㅠㅠ 인터뷰 유쾌하고 재밌어서 영구보존감이었는데... 오늘 너무 슬펐다

오늘 배운 것

• squash는 브랜치 머지할 때 pr에서도 진행할 수 있지만, 애초에 푸시하기 전에 squash 한 상태로 깔끔하게 만들어서 올릴 수도 있다.

오늘 한 일

• 어제 썼듯이, 앞으로는 우리 팀(?)도 매일 스크럼도 하고 카드도 배정 받겠지만 지라 카드를 처음으로 만져볼 일이 먼저 생겼다. 당장 업무로 긴급히 처리해야 할 일은 아니지만 어쨌든 한 번쯤은 해결하고 넘어가야 할 비교적 중요도가 낮은 일들이 이렇게 배정되는 것 같았다. 카드에 적힌 내용이 간단해서 나로서는 해석이 조금 필요했다. 어제 쿠버네티스 문서를 보는 한편으로 이 카드의 필요성을 이해하기 위해서 토코톡 코드를 조금 들여다 봤었다. 그리고 오늘 내가 생각한 게 맞는지 남훈님께 여쭤봤다.
• 생각한 내용은 맞았지만 이걸 해결하기 위해서는 git hooks를 알아야 했다. git commit을 하는 시점에 판단해야 하는 것들이 있기 때문이었다.
• 남훈님이 git hooks를, 케이님이 husky를 알려주셨다. husky도, git hooks도 어떤 식으로 동작하는 건지 알기까지 많이 어렵지는 않았다. 처음에는 husky를 보면서 사용하는 방법을 익히다가 패키지 설치 없이 git 자체에 내장된 기능을 사용해보려고 git hooks 문서로 넘어갔다. 한참 잘 확인해보고 있는데 git hooks를 그대로 사용하기에는 .git 디렉토리 자체가 로컬에서만 유효하기 때문에 팀에서 버전 관리를 하는 경우에는 비슷한 역할을 하는 패키지를 설치하거나 template directory를 이용해야 한단다. 다시 원점!?
• 그러다가 pre-commit이라는 패키지를 찾기에 이르렀는데 이건 내가 뭔가 잘못 사용해서인지 제대로 작동하지 않았다. 재도전이 필요하다. 이럴 거면 그냥 husky로...?

오늘 배운 것

• husky

• git hooks

• pre-commit