안녕하세요 킴스캐슬입니다:-)
저저번 글이었나요...? 다음번에는 실수관련된 글을 적겠다고 말씀드렸었는데 나름의 정리가 끝이난거같아서 적어보려합니다
저는 개인적으로 개발하는데있어서 만큼은 iOS개발자가 iOS개발을 잘하면 크게 문제가 없지 않을까라는 생각을 했었던것같습니다. 실제로 swift나 iOS관련된 개념이나 기술들만 집중해서 공부했었으니까요
실수 모음집이라는 글을 적게된 이유는 제가 실수한 부분들을 정리해보니 제가 지금 현 시점에서 부족한 부분을 객관적으로 알게되고 시간을 어디에 투자하면 될지가 명확해졌기 때문입니다
그리고 마지막에는 제가 느꼈던 교훈?을 적으며 마무리해보려합니다
(지금은 웃으며 이야기하지만 그 순간에는 식은땀 줄줄이었답니다...)
킴스님...저희 인증서가 이상해졌는데요...?
회사에 입사하고 나서 처음으로 겪어본것중에 하나는 fastlane을 통한 배포 자동화였습니다. 취준생 시절에도 뭔지는 알고있었는데 굳이 필요없다는 생각에 공부를 하지 않은 주제였습니다. 뭔지 알고있다는게 진짜 뭔지만 알고있다는거지 사용방법을 알고있지는 않았습니다
입사하고 온보딩기간에 노트북 환경세팅을 하면서 fastlane 설정을 했었는데 그때도 하라는대로 명령어만 치고 만들어진 스크립트를 실행만 했습니다. 당시엔 결과적으로 정상적으로 배포 자동화 프로세스가 돌아갔습니다
(이게 왜 되지...를 고민해봤더라면...)
이거 말고도 세팅해야될것들이산더미였던 터라 그냥 동료 개발자분들이 아주 잘 만들어두셨군...하면서 넘어갔었습니다
그러다가 한달쯤 지난 시점에 회사의 다른 프로젝트를 개발할일이 있어서 개발을 뚝딱뚝딱하고나서 자동배포 프로세스를 돌렸는데 엄청난 에러 폭탄을 맞게되었습니다
뭐지...? 뭐지...?하면서 안절부절 못하고있는걸 동료개발자분이 보시더니 오류를 보셨고
아 이거 Match파일이 있을건데 거기에 주소가 00으로 되어있을거예요. 그거 git으로 바꾸시고 다시 돌려보세요
라고 해주셨습니다
그 순간 Match파일?이 뭐지?라는 궁금증이 생겼으나 폴더에 떡하니 Match라는 이름이 파일이있는걸보고 아 그냥 여기 안에 있는 주소만 다른걸로 바꾸면 되는구나라고 생각했었습니다
그리고는 Match파일 안에 프로젝트 repository주소를 복붙해서 넣고 다시 프로세스를 실행했습니다. 근데 여전히 오류는 해결이 안되고 내가 뭔가를 잘못했나 싶어서 이것저것 만져보고 있었습니다. 그때 갑자기 옆자리 동료분이 github를 보시더니
어? 킴스님 지금 인증서가 이상한데요?
라고 하셨습니다...
저는 지금 뭘 잘못했는지도 모르겠고 지금 발생한 상황 자체가 이해가 되질 않았습니다. 말그대로 너무 혼란스러워서 머리가 새하얘졌습니다...
제 실수를 20분정도 동료 개발자분이 해결해주시고 어떤 문제였는지 설명해주기전까지 계속해서 죄송합니다를 연발하며 안절부절 못했던 기억이 납니다...
Match는 다수의 개발자가 iOS개발을 할때 인증서가 필요한 경우 인증서를 파일로 옮기는게 불편하고 매우 귀찮아서 git같은 주소에 인증서를 올려서 모두가 match를 통해서 해당 주소에 있는 인증서를 가져다 쓸 수 있는 개념입니다. 팀에서 사용하는 인증서 저장 github주소가 있는데 저는 그걸 모르고 그냥 프로젝트 github주소를 인증서가있는 github주소로 설정해버렸고 거기에 인증서가 없으면 새인증서를 만들어서 해당 주소에 넣게되는데 제가 그렇게 설정해버리는 바람에 기존에 모든 동료개발자 분이 바라보고 있는 인증서 파일이 있는 주소의 인증서가 자동 만료된 상황이었습니다
Match라는 명령어를 입력하고 엔터를 누르기전에 Match가 뭔지를 한번이라도 알아봤다면 하지 않았을 실수였는데 아무것도 모르고 입력해야하는 명령어만 보고 입력만하다가 저질렀던 실수였습니다
왜?를 늘 생각하는 개발자를 지향한다면서 누구보다 그러지 못했던 순간으로 기억에 남아있습니다
킴스님...main에다가 머지하셨는데요...?
이번 실수는 pr을 올릴때 merge대상을 develop으로 설정해야하는데 main으로 그대로 두고 그걸 눈치 못채고 merge를 해버린 실수도 있지만 그 뒤에 저질렀던 실수를 이야기해볼까합니다...
뭔가 실수했을때 내 모습.jpg
아이 괜찮아요 그럴 수 있죠 revert하면되요~
라는 동료 개발자 분의 말씀에 revert가 대충 되돌리는 기능이라는걸 진짜 대충 알고있던 저는 자신있게 merge커밋을 revert하게됩니다. 그런데 여기서 문제가 발생합니다
저는 revert를 써본적이 없었고 어떤 원리인지 모른채 안다는 착각으로 누르면 알아서 되돌려주는줄 알았고 갑자기 생긴 commit들이 대체 뭔지 몰랐습니다... 제대로 보지도 않고 아 이제 develop으로 이걸 옮기면 되겠구나하고 해당 커밋들을 develop에 push하게됩니다
아마 여기서 revert가 뭔지 아시는 분들은 경악을 하셨을지도 모르겠습니다
git revert는 되돌리는 commit을 만들어주는 기능입니다
즉, main에 merge된 커밋을 제거해주는 commit을 만들어주는 기능입니다. main에 그 commit들을 push해야 비로소 main에 merge된 코드들이 제거되게 됩니다
근데 제가 했던 짓(?)은 main에 머지된 커밋과 반대되는 commit을 develop에 push를 해서 main은 전혀 바뀌지 않고 develop입장에선 갑자기 이상한 commit이 push된 아이러니한 상황이 발생했습니다(나 그런 코드 없는데 왜 없애...?)
어찌저찌 해결은 했으나... git revert를 쓰기도 전에 알음알음 아는 얕은 지식으로 실행한 제 자신이 너무나 부끄러웠습니다... 안다는 착각이었던거죠. 처음 써보는 주제에 말이죠
이후에 main에 merge를 했던 상황자체는 제가 아니라 누군가가 실수로 할 수 있는 부분이라고 생각을 해서 기본 merge branch를 develop으로 변경하는것에대한 제안을 드렸고 모든 분들이 공감해주셔서 main으로 merge하는 실수를 하는 상황자체를 예방할 수 있었습니다
안다는 착각이 얼마나 무서운건지 처음 느껴봤던 경험이었습니다
킴스님...커밋이 너무 복잡해져요...
진짜 부끄러운 이야기지만 저는 git을 commit push commit push를 해왔습니다. 물론 이렇게 하면 절대로 내 이전 작업이 날라가지 않는다는 장점이 있지만 여기에 pull과 merge까지 하게되면 develop입장에선 merge commit이 중복되어 생기게되고 commit을 할떄마다 push를 했기때문에 commit정리가 제대로 되지 않아 git flow를 보는 팀원들입장에서 헷갈리게 만드는 상황을 야기했습니다
저는 항상 develop에 merge하기 전에 develop을 현재 작업 branch에 pull하는 습관이 있었는데 이러다보니 commit 히스토리를 깔끔하게 유지하기 어려웠습니다
결국 pull이 fecth와 merge를 순서대로 동작시킨다는걸 모르고 그냥 써서 생겼던 문제였습니다
동료분이 현재 작업 branch를 develop 최신화 하기 위해 merge(pull을 통한) 가 아닌 rebase라는 방법을 추천해주셨고 rebase에 대해서 알아보기 시작했습니다
(출처 https://tecadmin.net/git-rebase/)
rebase는 간단히 말해서 feature branch의 시작점을 현재 develop의 최신 시점으로 아얘옮겨오는것을 말합니다. 이렇게 하면 develop을 현재 branch로 pull해올때 추가되는 merge commit이 생성되지 않고 최종적으로 develop에 merge할때는 merge commit이 한번만 발생해 commit이 중복적으로 history에 남지 않고 깔끔하게 관리가 가능합니다
제가 commit push commit push를 한다고 말씀드렸을때 그렇게 하면 rebase시 forece push를 하지 않으면 오히려 rebase할때 꼬인다고 말씀하셨기도 했어서 rebase전에는 remote에 commit을 push하지 않은채로 rebase를 사용하기 위해서 commit을 들을 모으고 그 commit을 정리해서 다른 개발자분이 commit 히스토리를 파악하기 쉽도록 하고 remote에 올리기전에 rebase를 통해 develop기준 최신화를 진행하고 conflict를 해결한 후 최종적으로 commit들을 push한 후 merge해서 협업시 다른 개발자를 배려해줄 수 있는 방법을 배우게 되었습니다
저는 입사하고나서 iOS관련된 무언가로 실수하면 어쩌지 라는 불안이 많았습니다
근데 실제로 업무를 하다보니 iOS이외의 어떤걸로 실수를 할 때가 많았고 그 근본적인 원인은 무지와 애매하게 앎에서 온다는걸 알게되었습니다
특히 git관련해서 너무나 모르고 습관처럼 나만 편한방식으로 쓰고있다는걸 알게되었습니다. 협업하는데 있어서 누군가를 배려한다는건 당연하고 필수적이라고 생각하는 사람인데 그러지 못했다는 부끄러움이 다시한번 제 얼굴을 화끈하게 만드는것같습니다
실수한 내용들을 보면 지금당장 제가 시간을 투자해서 보완해야하는 부분은 git과 CI/CD툴인 fastlane이라는걸 알 수 있었습니다. 관성으로 쓰는것이 아닌 내가 정말 알고 쓰는게 얼마나 중요한지 알게해준 두달간의 경험이라고 생각합니다
왜를 늘 생각하는 개발자를 지향하지만 가장 왜를 생각하지 않고 행동했을때 어떤 결과가 나오는지를 보여주는 경험들이었습니다... 다시금 왜의 중요성을 깨닫게 되네요
내가 중요하지 않다고 생각한 것들이 어쩌면 중요한것들일 수 있으니 소홀히하지 않아야겠다는 다짐을 해보며 이번글을 마무리해보겠습니다
