우아한 형제들 블로그 ,
successful git branching model 참고.
1. Git Repository
Git repository
① Upstream Remote Repository
② Origin Remote Repository
③ Local Repository
가장 상위의 Upstream Repository는 최신 소스코드가 저장되는 원격 저장소이고
Origin Repository는 upstream을 fork한 원격 개인 저장소이다. Local은 내 컴퓨터의 개인 저장소이다.
2. Git flow
Git-flow에는 5가지 branch가 존재한다.
① master
② develop
③ feature
④ release
⑤ hotfix
1) master & develop branch가 존재한다
(develop branch는 master에서 시작된 branch이다)
2) develop branch 에서 bug를 수정한 commit 들이 상시로 추가된다.
3) 새로운 기능 추가 작업의 경우 develop branch에서 feature branch를 생성한다
(feature branch 는 언제나 develop branch에서 시작된다)
4) 기능 추가 작업이 완료되면 feature branch는 develop branch로 merge 된다.
(develop 이전 version에 포함되는 모든 기능이 merge 되었다면 QA 하기 위해 develop branch에서부터 release branch를 생성한다)
5) QA 중 발생한 bug들은 release branch에 수정된다.
QA 통과 후 release branch를 master & develop branch로 merge!
6) 마지막으로 출시된 master branch에서 version tag 추가
① why git >> git은 merging & branching을 쉽게 해준다.
② Decentralized but centralized
각각의 개발자들은 origin(central repo)에서 pull & push를 할 수 있는 동시에
sub teams/peer 의 changes 도 pull 할 수 있게 된다.
③ The main branches: master & develop
: orgin/master:
the source code of HEAD always reflects a production-ready state.
origin/devleop:
the source code of HEAD always reflects a state with the lagest delivered development changes for the next release. (= integration branch)
④ Supporting branches:
used to aid parellel development between team members, ease tracking of features, prepare for production releases & to assist in quickly fixing live production problems.
-> Unlike main branches, these branches always have a limited life time since they'll be removed eventually.
1) Feature branches : used to develop new features
for the upcoming/distant future release.
2) Release branches : support preparation of a 'new production
release' (minor bug fixed, preparation of a n-p-r)
3) Hotfix branches:
Hotfix branches are very much like release branches in that they
are also meant to prepare for a 'new production release')
- hotfix branch 는 release branches와 비슷하게
new production release를 위해 사용된다.
- feature branch가 develop branch로 merge된 후에 next release time frame이
가까워지면 testing/bug fix를 위해 new release branch를 생성한다.
- release branch는 develop에서 created 되어 develop & master로 merge된다.
- release가 끝나고 master에서 issue가 발견되면 hotfix branch를 master에서
생성한다. hotfix 가 complete 되면 develop/master로 merge 된다. 3. Git rebase
# What is git rebase?
>> Rebasing is the process of moving or combining
a sequence of commits to a new base commit.
Rebasing is most useful and easily visualized in the context
of a feature branching workflow.
** Git rebase는 일련의 커밋들을 new base commit으로 움직이거나 합치는 과정을 말한다.
말 그대로 commit들을 re-base한다는 뜻인 것 같다. **
*Git merge & rebase : Both commands are designed to integrate changes from one branch into another branch -- they just do it in very different ways.
둘다 한 브랜치에서 다른 브랜치로 변한 사항들을 통합시키기 위해 사용되는데
방법이 다를 뿐이다.
Rebase:
① 불필요한 merge commit들이 생성되는 문제를 해결하기 위해 사용
(지저분한 commit history That’s nono)
② 내 commit의 base를 변경하여 commit history를 일렬로 정렬
③ merge를 완벽하게 대처!
(Rebase replaces Merge)
매우 중요!!
branch당 commit을 max 2~3개 정도로 제한하고 rebase를 계속하자!
commit을 계속 남기면 conflict가 계속 발생할 가능성이 있다!Rebase 하는 법:
① 새로운 작업을 모두 마치고 push 하기 전에
1) Main branch 로 이동하여 remote main을 pull 받는다.
2) 내가 push 할 Feature branch 로 이동한다.
3) git rebase -i main를 진행한다.
4) 에디터가 나타난다.
② Rebase 하는 동안 squash 진행할 때
1) 제일 오래된 commit pick
2) 나머지는 squash
commit은 2~3개 정도로 제한
3) Esc -> :wq!
수정용 에디터가 하나 더 나타난다. 똑같이 반복해준다.
git log로 commit message 확인 -> push
(git push origin feature/login -f: force push)
