Git... 그 놈

Sinf·2021년 12월 16일
0

고민의 흔적

목록 보기
1/38
post-thumbnail

프로젝트 2일차

개발의 연속

왜 스프린트라고 얘기하는지 알겠다.
2주 안에 달성 목표를 잡고 빠르게 달려간다.

이렇게 작성해도 괜찮은가?

먼저, 2주 안에 서비스를 구축하기 위해 기능 구현에 목표를 두고 코드를 작성하고 있다. 그러다보니 내가 짠 코드에 대한 불안감이 생긴다.

이거... 괜찮은가?

아무리 생각해도 속도가 저하되는 로직들이 곳곳에 쌓여 있는데, 일단은 기능을 구현하고 나중에 더 좋은 방식으로 고치도록 해야겠다.

내가 한 일은 기능별로 정리하자

오피스아워 때 프론트엔드 코치님께서 얘기하신 부분인데, 내가 이런 페이지 작성했다. 이렇게 만들었다. 라고 하기보다, 이런 페이지를 구현하기 위해 어떠한 기능들을 구현했고, 어떤 스택을 사용했다로 초점을 맞추는 것이 좋겠다고 하셨다.

Git merge

혼자서 git을 사용할 때는 고려할 것이 별로 없었는데, 협업을 위해 사용하다보니 고민할 것이 생기기 시작한다.

먼저, merge할 때, 나는 항상 별다른 옵션 없이 사용했다.
마스터 브랜치에 남는 지저분한 커밋 목록들이 맘에 들지 않았다.

알고보니 merge에는 옵션이 존재한다.

  1. default: 옵션을 붙이지 않았을 때, 브랜치의 커밋 내용을 모두 가져와 병합한다.
  2. squash: 현재 브랜치에 병합될 브랜치의 변동사항을 커밋 없이 가져온다. 가져와서 커밋 한 번 깔끔하게 하면 병합된 브랜치에서는 지저분한 커밋 기록 없이 깔끔하게 한 번의 커밋으로 기록된다.
  3. rebase: 현재 브랜치 뒤에 병합될 브랜치의 커밋 목록을 가져온다.

이렇게만 보면 잘 이해되지 않는데, 다른 분들이 그림으로 잘 정리해놓으셨다.

간단하게 내가 필요한 정도로 정리하면,
feature 브랜치와 develop 브랜치 간의 merge의 경우 squash,
develop 브랜치와 master 브랜치 간의 merge는 rebase.

profile
주니어 개발자입니다. 🚀

0개의 댓글