WIL #16 Git Flow & Git Rebase
Git Flow & Git Rebase
Git flow
Git flow 사용
- default master 브랜치에서 디벨롭 브랜치를 만들어주는 것이다.
- 개발팀에서 대표 개발자가 작업물이 없는 빈 디벨롭 브랜치를 로컬에서 만들어주고 서버에 푸쉬해준다.
git branch develop
git push -u origin develop
# 이렇게 생성된 디벨롭 브랜치가 앞으로 프로젝트의 모든 히스토리를 관리(마스터는 축약된 완성본 버전만)
- 여기까지 완료했다면 다른 개발자들이 클론을 받을 준비가 되게 되고 여기서 브랜치를 생성해 각자 작업을 이어나가면 된다.
$ git flow init
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
master
Git flow 정리
- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
Basic flow
- master 브랜치와 main브랜치는 기능상으로는 차이가 없음 ~ _ ~
-
Main branch is used for production releases
Git rebase
MERGE & REBASE
- 2개는 방법만 다를 뿐 병합을 하기위해서 사용 하는것이다
- Rebase는 Merger를 대신한다
MERGE의 문제점
Git flow
git branch develop
git push -u origin develop
# 이렇게 생성된 디벨롭 브랜치가 앞으로 프로젝트의 모든 히스토리를 관리(마스터는 축약된 완성본 버전만)
$ git flow init
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
master
Git flow 정리
- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
Main branch is used for production releases
Git rebase
MERGE & REBASE
MERGE VS REBASE
REBASE 의 장점
REBASE 의 conflict
Conflict는 commit과 commit 사이에서 일어나는 작업 내용 사이의 충돌이므로, 세 개의 커밋이 한 번에 충돌 날 가능성이 있습니다.
REBASE를 위한 Squash
REBASE 의 장점
새로운 작업을 모두 마치고 push 하기 전에는
- Main branch 로 이동하여 remote main을 pull 받는다.
- 내가 push 할 Feature branch 로 이동한다.
git rebase -i main
를 진행한다.
Rebase 하는 동안 squash 진행할 때에는
- 가장 오래된 commit을 pick 한다.
- 다른 커밋 메세지는 가장 오래된 commit을 기준으로 squash 한다.
- 다른 커밋의 작업 내역이 없어지는 것이 아닙니다.
- Esc -> :wq! 로 창에서 빠져나온다.
REBASE 사용
놀라지 마세요! 수정용 에디터가 하나 더 나타납니다.
- 최종적으로 이 rebase된 커밋의 내용을 작성하는 부분.
- 현재까지 적은 커밋 메세지가 전부 나타난다.
- 불필요한 내용을 제거하고 현재 수정 내역에 대한 커밋 메세지를 정
성껏 작성한다. - Esc -> :wq! 저장하고 에디터에서 빠져나온다.
Successfully rebased !
- 성공했다면 git log로 깔끔해진 커밋 메세지를 한 번 감상한다.
- push를 합니다.
Rebase 후 push 하기
- Rebase는 commit history를 정리하는 역할을 한다.
- 같은 브랜치에서 Rebase를 할 때마다 history가 달라질 수 있다.
- 수정 사항이 추가로 생긴 후 다시 rebase하면 history가 무조건 달
라진다. - git은 history가 다른 branch의 push를 허용하지 않는다.
git push origin feature/login -f
-f 옵션을 사용하여 force
push를 진행한다.
REBASE 충돌 해결
- 충돌이 일어난 경우 Rebase가 진행되지도, 끝나지도 않고 도중에
멈춰 있어, 매우 당혹스럽다. - 터미널이 (rebase ~ 1/6) 과 같은 메세지로 rebase가 진행중임을
알려주니 겁먹지 않도록 하자! - 충돌은 충돌일 뿐, 해당하는 코드를 수정 후
- Git add .
- (Git commit은 하지 않는다. 수정 사항이 없으니까)
- Git rebase ㅡㅡcontinue를 진행한다
- 멈춰 있던 리베이스가 진행된다.
- 충돌이 여러번 나면 그 때마다 충돌을 해결하고
git add . / git rebase ㅡㅡcontinue를 반복한다. - 계속 해결이 안된다면, git rebase ㅡㅡabort로 아예 rebase를
진행하기 전 상황으로 돌아갈 수도 있다.
git 명령어
- Git reset soft vs hard
- Git log
- Git reflog
- Git checkout
- Git stash & git stash apply & git stash clear
Author And Source
이 문제에 관하여(WIL #16 Git Flow & Git Rebase), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@shinisgood/WIL-16저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)