머지?
별로 한 것도 없는데 2주차 회고 시간이 돌아왔다.
이번 주 나의 룸메이트는
거의 매일 함께 있었다. 머지하려고 하면 먼저 찾아와서 “이 브랜치와는 자동적으로 머지될 수 없습니다.” 그래도 마우스를 올리면 그래도 해결할 수 있다는 안내가 뜨는데…. 결국 마주하는 건 수많은 conflict 에러 였을 때의 심정이란ㅜ 게다가 해결할 수 있다면서 깃헙 추천 해결방법으로는 시작조차 불가능한 경우가 많았다. (물론 이건 내가 아직 그 방법을 제대로 사용하지 못해서였을 가능성이 높다.)
부모님보다 자주 보고, 동생 전화보다 자주 화면에 뜨던 “컨flict”. 어쨋든 브랜치 전략을 대폭 수정하게 된 날 빌드오류를 해결하면서 깔았던 깃허브 데스크탑 덕분에 더이상 오래 잡고 있지 않을 수 있었다. 자취생에게 개인 공간이 얼마나 소중했는지 깨닫게된 4일(?)이었다
브랜치는 어떻게 관리되어야 했을까
룸메이트와 멀어지던 날 브랜치 전략을 대폭 수정하게 되었다. 사실 피드 게시글 mapper 쪽에서 빌드 에러가 떴고, 아예 실행을 못하고 있는 상황에서 재곤님께서 흔쾌히 도와주겠다고 하신게 회의방에 들어간 이유였다.(감사합니다 재곤님ㅜ 실행 안되는 동안 너무 답답했습니다,,ㅜㅜ) 코드 짤 때, 엉성한 설정을 해두는 바람에 문제가 생겼던…. 어쨋거나 회의방의 주제는 “왜 server 쪽 코드를 머지하는데 client 쪽 파일에서 컨플릭트 에러가 나는가”로 바꼈다. 애초에 client 파일을 확인할 수 없는 상황이어서 어디서 문제가 생겼는지 눈으로 볼 수 없었는데, “뭘까요?”만 반복하던 와중에 멘토님께서 회의방에 찾아오셨다. 그게 어디서부터 꼬이기 시작한건지 다시 생각해보는 전환점이 되었다. 프론트와 백의 코드가 마구 섞이기 시작한건 레포지토리가 분리되지 않은 상황에서 당연히 일어날 수 있는 일이었다고 한다.
그 때 부터 긴급회의가 시작됐다. 브랜치 전략을 바꿔야 하는지, 바꾼다면 어떻게 바꿔야하는지, 바꾸지 않았을 때 어떤 문제가 생길 수 있고 지금까지 어떤 에러가 있었는지 .. 에 대한 돌고 도는 회의였다. 마지막까지 다들 열정적으로 의견을 내주시고 상황에 대해 설명해주셔서 비교적 짧은 시간동안 나름 좋은 해결 방법이 나왔다.(고 생각한다.)
물리적인 해결방법은
최후의 수단이고, 절대 끝까지 보류해야하는 방법이라고 생각했다. 그러나 이번 conflict에러나 깃 브랜치 전략을 바꾸면서 논리적인 해결 방법과 물리적인 해결 방법 중 무조건 우선 시 되어야하는 방법은 없다는 것을 알게 되었다. 그냥 에러를 해결하면서 더 적은 리소스를 사용하는 방법이 상황에 맞는 방법이라는 점.
이번 주 회고(라고 쓰고 내용은 아무 말)
동네에 아메리카노 맛집을 찾았고, 하루에 3잔에서 4잔 정도 마신 것 같다. 밤샘에 효과 좋은 아메리카노 파우치도 판매중이었다.
-프로젝트에서 일정 기간 안에 주어진 일을 하는 것은 중요하다. 컨플릭트 에러를 너무 오래 잡고 있지 않는 것도 비슷한 것 같다. 그래서 깃허브 데스크탑을 적극 활용해보기로 마음 먹었다.
-너무 급하게 하려고 하면 쉽게 해결할 수 있는 일을 더 복잡하게 만드는 실수를 하기도 한다. 빠른 해결과 조급한 대처는 다르다는 걸 느꼈다. (conflict를 빨리 해결하겠다는 마음에 설정 파일을 전부 날려버린 일.)
-지금 프로젝트는 여러 기능을 구현해보기만 좋은 기회라고 생각했는데, 더 다양한 주제로 소통하고 의견을 나눌 수 있는 더 좋은 기회였다.