왜 스프린트라고 얘기하는지 알겠다.
2주 안에 달성 목표를 잡고 빠르게 달려간다.
먼저, 2주 안에 서비스를 구축하기 위해 기능 구현에 목표를 두고 코드를 작성하고 있다. 그러다보니 내가 짠 코드에 대한 불안감이 생긴다.
이거... 괜찮은가?
아무리 생각해도 속도가 저하되는 로직들이 곳곳에 쌓여 있는데, 일단은 기능을 구현하고 나중에 더 좋은 방식으로 고치도록 해야겠다.
오피스아워 때 프론트엔드 코치님께서 얘기하신 부분인데, 내가 이런 페이지 작성했다. 이렇게 만들었다. 라고 하기보다, 이런 페이지를 구현하기 위해 어떠한 기능들을 구현했고, 어떤 스택을 사용했다로 초점을 맞추는 것이 좋겠다고 하셨다.
혼자서 git을 사용할 때는 고려할 것이 별로 없었는데, 협업을 위해 사용하다보니 고민할 것이 생기기 시작한다.
먼저, merge할 때, 나는 항상 별다른 옵션 없이 사용했다.
마스터 브랜치에 남는 지저분한 커밋 목록들이 맘에 들지 않았다.
알고보니 merge에는 옵션이 존재한다.
이렇게만 보면 잘 이해되지 않는데, 다른 분들이 그림으로 잘 정리해놓으셨다.
간단하게 내가 필요한 정도로 정리하면,
feature 브랜치와 develop 브랜치 간의 merge의 경우 squash,
develop 브랜치와 master 브랜치 간의 merge는 rebase.