티스토리 뷰

기능 출시를 위해서 지지난주까지 정말 열심히 불태우며 개발을 했습니다. 제 부서는 바로 실시간으로 서비스를 제공하는 부서가 아니라 라이브러리 개발을 하고 있기 때문에 다른 부서들이 해당 라이브러리를 사용할 수 있도록 내부 출시(?)일을 맞춰야 했죠. 그런데 개발 이외에 잡무들도 밀려오고 회의도 들어가야하고, 언제나 그렇듯 예상치 못했던 문제들과 예외 상황들로 거의 밤 세우듯이 마감일정을 맞춰나가고 있었습니다. QA 팀에서는 딸리 내놓으라고 닥달했지만 저는 그냥 정신줄 놓아버렸습니다. 


"아몰랑, 다음주에 줄거야 알아서해(=무리한 야근은 안 할거임, 아무튼 야근 안 할거임)"


이렇게 되면 내부 라이브러리인 경우에는 일단 현재 소스에서 branch를 하나 따서 해당 branch를 검증용으로 사용하는 경우가 많습니다. 제가 하던 개발 작업은 이제 완료하게 되면 새로 딴 branch와 HEAD 두 군데에다가 같이 밀어넣어야 하게 되죠. 그 때에 하는 작업이 바로 cherry picking 입니다.


cherry picking


직역해서 '체리를 딴다'라고 하면 대충 짐작은 될수도 있을 것 같습니다. 이러한 단어를 가장 쉽게 접하는 곳이 바로 git일겁니다.


git cherry-pick commit-hash


여기서 git이 수행하는 내용 자체를 cherry picking이라고 합니다. 보통은 다른 branch에 있는 커밋을 이쪽 branch로 가져오는 것을 이야기하죠. 그렇게 하는 이유는 여러 가지가 있는데 첫번째는 위와 같이 이미 branch를 땄는데 HEAD에 넣은 커밋 내용을 가져오고 싶을 때 사용하기도 하고, 여기서 겪었던 다른 상황은 전체 빌드가 멈춰진 상황에서 커밋을 여러 명이 동시에 수행해서 충돌이 일어나서 충돌에 상황없는 커밋들만 선택해서 적용하고 나머지는 revert 하겠다고 할 때에도 cherry picking을 한다고 합니다.


또 다른 사용처는 기능이 여러가지 제공되고 있는 라이브러리나 모듈이 있다면 원하는 기능들만 쏙쏙 빼서 사용할 수 있도록 경량화하거나 캡슐화할 때에도 많이 사용하기도 합니다. 특히 빈번하게 업데이트 되는 오픈소스가 있다면 원하는 기능이나 버그 픽스가 있는 커밋만 선택하는 것을 이야기할 때에도 사용합니다.


소프트웨어 개발에서는 이렇게 원하는 기능만 쏙쏙 빼서 적용하는 것으로 많이 사용되는 반면 일반인들이 이야기할 때에는 무지 쉬운일을 할 때, 누워서 떡먹기와 비슷한 용법으로도 사용하므로 상황에 따라서 구분해서 들으면 좋을 것 같네요. 


제 상황에서는 이미 적용해야 되는 branch가 두개가 되었다면 각각에 commit을 push하기 보다는 우선순위에 따라 mainline이나 branch에다가 한쪽만 먼저 push를 해두고 테스트를 수행한 다음, 나머지 branch에서 git cherry-pick을 수행하는 것이 실수를 최소화할 수 있는 좋은 방법인 것 같습니다. 물론 이러한 상황이 닥치면 이제 테스트를 양쪽 branch에서 각각 해야하는 것이 부담이 되어 테스트 시간이 늘어나게 되니 가장 좋은 것은 마감을 잘 지키는 것이겠죠 ㅠ


저는 회사에서의 무리한 야근은 절대 하지 말자는 주의로 일정을 짰지만, 나중에는 회사에서 야근은 안 해도 어쩔 수 없이 온가족이 자고난 다음에 집에서 새벽에 조금씩 더 일하게 되는 상황이 벌어지게 되었네요. 일정관리는 언제나 너무나 어려운 것 같네요 ㅠ 항상 여유를 두고 일정을 짰지만, 이번에는 정말 오랜만에 마감에 쫓겨 집중해서 개발만 열심히 한 것 같습니다.



공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/04   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
글 보관함