{ PR ⇒ Merge ⇒ pull ⇒ local Merge } 로 이루어지던 Git Flow가 Git Rebase 라는 명령어와 함께 조금 바뀌었다.
{ PR ⇒ Merge ⇒ Rebase ⇒ Pull ⇒ Rebase } 정도로 보면 되겠다.
개발을 하다 보면 중간 중간 의미없는 Commit이 남을 떄가 많았다. 그 중 대다수를 차지하는 경우가 작업도중 다른 브랜치로 가야해서 남기는 WIP이었는데, Rebase를 통해 브랜치 당 커밋이 하나만 남게 되어, 팀 레포에는 각 브랜치에 관한 커밋 메시지만 남아서 엄청 깔끔한 커밋 히스토리가 될것으로 예상된다.
아쉬운 점은 중간 중간 어떤 작업을 했는지 남지 않아서 상세한 내역은 file change를 살펴보아야만 알 수 있다는 것인데, 지금 생각나기론 그래서 커밋메세지의 헤드만 적는게 아니라 본문도 성실히 남겨야 한다는 말이 있었던 것 같다.
리베이스를 하면 브랜치당 커밋이 하나만 남게 되고, 그렇다면 커밋 메세지 타이틀은 하나만 있으니 상세내역은 바디에 담아야 되고, 그러다 보니 상대적으로 커밋 메시지 바디의 중요도가 높아지는게 아닐까? 굳굳!!! 이제 정리가 되네 ! ㅎㅎ
Unit Test
BE에서 중요도가 훨씬 높다는 Unit Test!
기억에 남는 내용으로는 FE에서는 Cypress라는 툴을 사용해서 End to End Test를 자동화 할 수 있다는 이야기, BE에서 Unit Test 진행할 때 Jest라는 라이브러리를 사용한다는 이야기가 가장 기억에 남는다.
그리고 “순수 함수가 아니라 사이드 이펙이 발생하는 함수의 경우에는 유닛트스트가 가능한가요? “라는 질문을 남겼는데, 답변이 없었었다. ㅠㅠ
대신 BE동기 종민 님이 “그래서 함수를 잘게 쪼개어 순수함수 단위로 테스트가 되도록 하지 않을까요?” 라는 말을 남기셨는데 아주 좋은 대답이지 않았나 생각한다.
그리고 개인적으로 지금 진행하는 2차프로젝트 같은 경우 일정이 너무 빠듯해서 BE에서 유닛테스트에 힘을 써버리면 프로젝트 완성이 힘들어 질것 같다는 생각을 했다. 이래서 “TDD”와 “일단 구현 먼저” 의 싸움이 되는건가 라는 생각을 하게 되었다. ㅎㅎ 상황에 따라 다르겠지?
소셜 로그인
내가 맡은 티켓은 아니지만… 동기 분께서 질문을 계속 주시는 덕에 많은 부분을 배우는 중이다. 굳굳띠.. 역시 질문을 받고 대답을 하는 과정, 토론하는 과정, 페어 프로그래밍 해보는 과정에서 정말 많이 배우는 것 같다.