• merge-commit 전략: 제주도 산방산 그래프 만들기
• squash 전략: 작업을 하다보면 기획이 바뀌는 경우가 자주 발생한다.
  • fix(comment): 기획에 의해 문구 변경
  • fix(comment): 기획에 의해 문구 변경2
  • fix(comment): 기획에 의해 문구 변경3
  • ... → squash (hash)
  • 하나의 코드 변경점에 대한 여러 개의 커밋 작업을 하나로 합쳐준다.
• rebase 전략: 강요할 수는 없다. rebase가 정답은 아니다.

💥 코드 충돌(conflit)

• 같은 곳에 각자 브랜치에서 작업한 후 merge 한 상황
  • HEAD : 내 코드
• 충돌을 해결하고 merge commit을 하면 그래프가 커질 수 밖에 없다.
• rebase 방식이 표준이 되지 못한 이유 → 위험성이 있다.
  • base(dev) 에서 명령어
    • git merge "작업 브랜치1"
  • 작업 브랜치2 에서 git rebase dev 했더니 rebase 충돌 발생
    • confilt을 해결하고 git rebase —confinue
  • base(dev) 에서 다시 git merge "작업 브랜치2"
  • 작업 브랜치2는 remote에 이미 올라가 있는 commit을 강제로 덮어쓰면서 git push —force
• 작업 브랜치1은 다시 base(dev) 기준으로 rebase 해야 한다.

⇒ 커밋하기 전에 한번 pull 받고 rebase 하는 작업이 반드시 필요하다.

🍒 선택적 반영(cherry-pick): 배포 또는 옛날 커밋 되살리기

• 반영될 필요가 없는 커밋을 가짜 커밋으로 pull 받은 것처럼 만든다.
  • 실제 커밋된 해시코드와 cherry-pick 한 해시코드는 다르다.
  • base와 작업 브랜치의 해시코드를 비교해보면서 현재 상태가 모두 pull 되어있는지 확인
• 배포 시점(dev 👉 main) 에 일부 커밋이 오늘 배포되면 안되는 상황
  • git merge dev —no-ff -m “release/##” →배포되어서는 안되는 커밋까지 배포되어버린다.
• 새로운 배포용 브랜치를 하나 따서 dev에서 cherry-pick한 커밋만 배포한다.
  • 그 다음 dev 는 반영되지 않은 커밋 외 배포 완료된 상태를 맞춰야한다.
  • dev에서 main 기준으로 rebase를 한번 맞춰주자!
• 연관이 되어있는데 일부만 cherry-pick 하는 경우는 별로 없다…

🔙 코드 되돌리기(Rollback)

• reset(Hard) : 장애 냈던 이유를 없애버림 → 기억 횡령
  • 장애 관리도 중요한데 reset 해버리면 또 같은 실수 반복할 수 있다…
• revert: 장애가 나기 전으로 다시 새 커밋을 만드는 작업