Home

인사 안녕하세요. 데이블 Service Front-end Team(SF Team)에 한재원이라고 합니다. “여러분은 혹시 Git 때문에 고통받고 계시지 않으신가요?” 저는 올해 2월에 데이블에 합류하게 되었는데요. 거기에 수식어 하나를 덧붙이자면, 2월에 ‘개발자 첫 커리어’를 데이블로 시작했습니다. 즉 아직은 귀여운(?) 병아리 개발자인 셈입니다. 갑자기 웬 고해성사냐, 라고 생각하실 수도 있겠지만 잠깐 기다려보세요. 할 말이 있습니다. 그것은 바로 저 역시 초반부터 Git으로 고통받았기 때문입니다. 개발자로서 실무에서 협업하는 상황을 처음 겪다 보니 초반에는 걱정 없이 잘 될 줄만 알았던 Git이 꼬이기 시작했습니다. 특히 엄청 다양한 Git 사례(문제)들이 발생했기 때문에 막상 검색할 때도 어떻게 할지 몰랐습니다. 단순히 rebase 방법, revert 방법 이런 것들은 검색을 통해 찾을 수 있겠지만 현재 우리 프로젝트에 놓인 꼬여있는 브랜치(Branch)와 커밋(Commit)을 예쁘게 풀어줄 최적의 방법을 찾기란 어려웠죠. 안녕하세요. 데이블 Service Front-end Team(SF Team)에 한재원이라고 합니다. “여러분은 혹시 Git 때문에 고통받고 계시지 않으신가요?” 저는 올해 2월에 데이블에 합류하게 되었는데요. 거기에 수식어 하나를 덧붙이자면, 2월에 ‘개발자 첫 커리어’를 데이블로 시작했습니다. 즉 아직은 귀여운(?) 병아리 개발자인 셈입니다. 갑자기 웬 고해성사냐, 라고 생각하실 수도 있겠지만 잠깐 기다려보세요. 할 말이 있습니다. 그것은 바로 저 역시 초반부터 Git으로 고통받았기 때문입니다. 개발자로서 실무에서 협업하는 상황을 처음 겪다 보니 초반에는 걱정 없이 잘 될 줄만 알았던 Git이 꼬이기 시작했습니다. 특히 엄청 다양한 Git 사례(문제)들이 발생했기 때문에 막상 검색할 때도 어떻게 할지 몰랐습니다. 단순히 rebase 방법, revert 방법 이런 것들은 검색을 통해 찾을 수 있겠지만 현재 우리 프로젝트에 놓인 꼬여있는 브랜치(Branch)와 커밋(Commit)을 예쁘게 풀어줄 최적의 방법을 찾기란 어려웠죠. 아, 이래선 안 되겠구나 병아리 개발자라며 미숙한 티를 내면서 자기 위로를 해봐도 소용없습니다. 회사에 합류한 이상 저는 더 이상 투정 부리는 아마추어가 되면 안 됐기 때문이죠. 그리하여 본격적으로 Git에 관해서 공부할 필요성을 느꼈습니다. 또한 공부한 내용을 동료들에게 공유하는 시간을 가지면 Git에 대해 익숙하지 않은 동료분들께도 도움이 되겠다고 생각했죠. 이 글은 해당 세션의 발표 내용을 글로 요약하여 쓴 것입니다. “원리만 이해한다면 자유자재로 Git을 다룰 수 있다.” 저희 SF Team 리드이자 CPO인 군우님께서 하신 말입니다. 사실 이 말이 처음에는 잘 와닿지 않았습니다. 그 당시만 해도 그냥 Git을 다루는 게 어려웠기 때문이죠. 하지만 Git을 개인적으로 학습하면서 정리하다 보니 ‘아, 정말 Git의 흐름을 잘 알고 있다면 전혀 어려울 일이 아닐 수도 있겠다’는 생각이 들었습니다. 반대로 말하면 대부분의 Git을 어려워하는 사람들은 Git의 흐름과 원리를 제대로 이해하지 못하고 있을 확률이 높다고 생각했습니다. 저의 경험을 비추어 보았을 때 Git을 어려워하는 이유는 이런 것 같습니다. Git을 처음에 마주칠 때는 보통 개발에 발을 딛은 지 얼마 되지 않은 상태에다가, 방대한 Git 용어들과 익숙하지 않은 시커먼 화면(terminal)에서 무언가를 쳐야 한다는 공포감 때문에 ‘Git은 너무 어려워!’하고 머릿속에 여전히 남아 있는 게 아닐까요. 다시 돌아와서 어쨌든 Git은 원리만 이해한다면 아주 심플하게 활용할 수 있다고 생각합니다. 지금부터는 Git에 기초적이지만 기반이 되는 개념들을 통해 Git과 친숙해져 보는 시간을 가져 보도록 하겠습니다. 또한, 제가 실무에서 경험했던 Git과 관련된 사례를 영상에서 소개하고 해결하는 방법이 포함되어 있으니 참고해주세요. Git은 한마디로 관찰자다 흔히 Git을 쉽게 비유하여 설명할 때 카메라로 사진을 찍는다(캡처한다), 문서를 작성하고 저장할 때 ‘작업물_최종.ppt’, ‘작업물_진짜최종.ppt’ 같은 것을 예시로 듭니다. 저는 Git을 이렇게 비유하고 싶습니다. “Git은 관찰자다!” 우리는 무언가를 작업할 때 모든 걸 기억하지 못합니다. 인간이 가진 한계가 있기 때문이죠. 그렇기 때문에 이 작업을 기억할 수 있도록 Git이라는 (모든 걸 내다볼 수 있는 전지전능한) 관찰자에게 도움을 요청한다고 생각해보자고요. 즉 Git(관찰자)은 나를 도와주는 협업의 관계인 셈이죠. Git이라는 관찰자에게 ‘내가 작업하고 있는 이 디렉터리의 변화를 모두 관찰해줘!’라고 도움을 요청하면 Git은 ‘알겠다!’고 하며 등장합니다. git init 위에서 말한 도움을 요청하는 메시지가 바로 git init입니다. 관찰을 원하는 디렉터리 안에서 git init을 외치는 순간 Git이라는 관찰자를 고용한 셈인 거죠. (디렉터리 안에서라는 말은 터미널상 Git에게 도움을 요청하려는 프로젝트 디렉터리에 위치해 있는 것을 말합니다)