Intro
- 오늘 사실상 팀 과제 기능구현을 마무리하는 시간을 가졌다. 발표가 다음주 월요일까지이지만 테스트와 수정, 머지하면서 발생할 수 있는 여러 변수를 생각해본다면 오늘 대부분의 기능이 마무리되어야한다고 생각이 들어서 팀원들과 상의 후 정하였다.
- 내일 할 테스트시나리오를 작성하면서 프로덕트를 만든다면 일이 어어어어엄~청 많은것빼곤 지금과 비슷하게 흘러가지않을까싶었다.(물론 회사에 가면 많이 다를것같긴하다.)
- 어제부터 시작해서 오늘 신나는 PR과 충돌등 오늘은 Git에 관한 다양한 경험을 하였다.
Pull Request
- 사전캠프때 사전과제를 하면서 깃에대해 익숙해지는 시간을 가졌고 그럴 수 있었던것은 매니저님이 친절하게 알려주신 PR의 개념때문이었다.
- PR은 내가 만든 코드를 회사 혹은 팀의 코드베이스에 바로 merge 하지 않고 merge를 요청하는 것이다. 요청한다는것은 응답하는 사람이 있다는 뜻이다. PR을 받는 담당자와 만약 코드리뷰를 한다면 팀원들의 리뷰를 다 응답하고 내 코드에 적용해야지 그때서야 PR을 할 수 있다는 것이다.
- 그러나 우리는 같은 팀원들이기때문에 누가 PR을 검토하고 승인하는 개념은 없다. 다만 PR을 잘 작성하는것에대해서는 훈련이 필요함을 배우는 시간이었다. 빨간색 박스가 바로 내가 연습하며 앞으로 채워나갈 목록들이다. 오늘 PR을 올리면서 작성해보니 이게 기록되어있고 없고의 차이가 상당하겠다는 생각이 들었다.(코드베이스가 크면 클수록 더..)
Conflict
- 내가 작업단위를 잘못나눠서인지(아마 이게 맞을듯하다..) 올리는 족족 Conflict가 생겼다. 그리고 나를 포함한 모든팀원들이 커밋을 파일뭉터기 단위로 하다보니 Conflict날 확률은 당연히 쭉쭉 올라갈 수 밖에 없었다.
- 충돌을 잡는일은 그리 어렵진 않았으나 충돌을 잡느라 쓰는 시간이 아까웠기에 앞으로 git 습관을 최대한 작은 단위의 파일을 많이 커밋해서 충돌이 날 확률을 줄이고 충돌이 나더라도 쉽게 잡을 수 있도록 신경써야겠다.
rebase
- 평소 git을 사용하면서 늘 생각했던 부분이 내가 작업하고있는데 PR이 올라와서 코드베이스가 업데이트 되었다면? 이전의경우에는 내가 작업하던 브렌치 놔두고 dev에 가서 pull 받고 다시 돌아오는데 늘 했던 생각이 이렇게 하는게 무슨의미가있나싶었다. 어차피 내가 작업하는 브렌치의 베이스는 이미 최신이 아닌데 그러면 내가 PR올릴때 높은 확률로 Conflict 나는게 아닌가? 라는 생각이었다.
- 평소 미뤄뒀다가 오늘 찾아보니 rebase라는것을 사용하여 내 브렌치의 코드를 업데이트한다는 사실을 알았다! rebase는 말 그대로 내 Base를 바꾸는것을 뜻한다. 내가 Base를 이전에 잡아놓았었는데 누군가가 dev에 merge를했다면? 내 Base는 dev의 현재와 비교해 과거Base가 될 것이다. 그럴때 아래 그림처럼 Base를 바꿔줘서 브렌치를 최신상태로 유지하는 것이다.
출처: 아이군의 블로그, Git Pull시에 자동으로 Rebase적용하기 - rebase에 관련된 내용을 찾다보니 git history를 일직선으로 아주아주 깔끔하게 남길 수 있다고해서..! 나도 다음 팀과제때 도전해봐야겠다!
여기에 rebase에대해 잘 설명되어있다.
Outro
- git은 알면 알수록 배울게 많고 참 편리하다는것을 느끼게된다. 왜 많은개발자들의 사랑을 받는지 알겠다. 아직 혼자서 작업하거나 프로젝트 사이즈가 작기에 git을 사용하는게 굳이? 라는 생각이 들 수준이지만 조금만 커지고 개발자들이 늘어나면 history를 볼 일이 많아질것이고 그렇게되면 rebase라던가 여러 브렌치 관리전략들을 사용하게 될 시기가 올 것이라 믿는다?!? 끗!
잘부탁드립니다!