[Git & Github] Git Flow와 Git Rebase

이승연·2020년 12월 29일
0

Git & Github

목록 보기
2/4
post-thumbnail

Git Flow

  • 원래는 main과 feature만 썼었다... 그런데 이게 바뀔거다.. 다음과 같이...
    main : 제품으로 출시될 수 있는 브랜치
    develop : 다음 출시 버전을 개발하는 브랜치
    feature : 기능을 개발하는 브랜치
    release : 이번 출시 버전을 준비하는 브랜치
    hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

예시

  • 일단 내 맘대로 branch를 따는게 아니라 git flow init을 하면 각 브랜치에 대해 어떻게 이름을 설정할지 깃에서 물어보는 과정을 거쳐 알아서 만들어준다.
  • develop branch : 메인해서 하기엔 좀 그러니까 새로운 버전이나 새로운 기능을 작업하기 위해 파는 브랜치
  • feature branch : develop branch에서 따오고 디벨롭에 pr해라
  • release branch : 여기서 버그를 고치자. 고치면 디벨롭에 푸쉬를 하고 그걸 feature에서 또 풀을 받아와야한다. 왜? ㅠㅜ 난 풀해오는게 너무 시러

메인에서 에러가 생긴 경우 어떻게 해야 하나

  • 메인에서 hotfix라는 브랜치를 따준다.
  • 픽스 후 메인에 merge하고 develop, feature branch에서는 또 풀을 받아야한다.

Git Rebase

  • 브랜치와 브랜치를 합칠 때 쓰는게 merge
  • rebase도 같은 개념이나, 아주 다른 방법을 써서 한다!
  • merge의 문제점:
    • 불필요한 merge commit 생성: 모든 feature branch마다 "merge commit"이 남아 지저분
    • 복잡한 프로젝트 history: 내가 한 작업과 다른 사람이 한 작업 내역이 겹쳐서 구분이 어려움
  • 이러한 merge의 문제점을 해결하기 위해 나타난 아이가 rebase
    • 내 전에 커밋했던 애들은 내 뒤에, 내 다음에 커밋했던 애들은 내 앞에 보임.
    • 모든 팀원들이 리베이스를 하는 것이 중요
    • 다른 branch의 완전한 작업이 끝난 commit을 합쳐서 다시 base화 한 후 commit 내역을 일렬로 잘 정리하는 것이 rebase

Git Squash

  • 내 모든 커밋들이 하나로 합쳐지는 것

이제부터는...

  • 다른 커밋들 앞에는 s라고 써주면 됨


알아두면 좋은 Git 명령어

  • Git reset soft vs hard
  • Git log
  • Git reflog
  • Git checkout <commit>
  • Git stash & git stash apply & git stash clear

0개의 댓글