강의
오늘 배운 것
Git Branch 전략
1. Git Branch 전략 종류
- Git Flow : Vincent Driessen이 2010년에 제시한 Git 브랜치 전략, 다양한 버전이 있고 롤백이 잦은 모바일 애플리케이션 개발에 적합한 flow임
- Github Flow: 수시로 배포가 일어나서 잦은 배포 주기를 가지는 웹 프로젝트 개발에 적합한 flow임
2. git flow
- 브랜치 수가 많고 여러 규칙이 있어서 규모 큰 플젝에 적합함
- 배포 주기가 잦지 않고 롤백이 잦아 버전 관리가 필요한 모바일 플젝에 적합함
- 크기 main, develop, release, hotfix 브랜치가 있음
2-1. 각 브랜치 규칙
- main: 운영환경에 배포될 수 있는 코드 모으는 브랜치
- develop: 다음 버전을 개발하는 브랜치
- feature: 새로운 기능을 개발하는 브랜치, develop 브랜치에 생성하고 기능 개발 완료되면 develop에 merge함
- release: 새로운 버전의 배포를 위한 브랜치, develop 브랜치에서 생성하고 배포 전 버전 사소한 데이터 수정 및 버그 수정에 사용됨. 배포 준비 완료되면 main, develop에 모두 merge함
- hotfix: 운영환경에 빠르게 수정해야할 버그가 있을 때 main에서 생성함. 버그 수정 끝나면 main, develop에 merge함
3. github flow
- 브랜치가 main과 feature로 두개만 존재함
- main에만 엄격한 규칙을 적용하고 나머지 브랜치에는 규칙 적용 안 함
3-1. 각 브랜치 규칙
- main: 언제든 배포 가능 상태를 유지해야함. main으로 merge 전 엄격한 테스트 거쳐야 함
- 나머지 브랜치: main에서 생성하고 이름, 규칙 등 자유롭게 결정함
Git Merge 전략
1. Git Merge 전략 종류
- Merge Commit
- Rebase and merge
- Squash and merge
2. Merge
- fast-forward
- a 브랜치를 머지할 때 조상 브랜치인 master에 변경점이 없다면 master 브랜치를 바로 a브랜치로 이동해 merge하는 것
- 3-way-merge
- 두 브랜치 모두에 변경사항이 있을 경우 merge하는 가장 일반적인 경우
- 각 브랜치의 최신 commit과 공통 조상 커밋을 비교하고 새로운 commit을 만들어 merge하는 전략
3. Rebase Merge
- Rebase를 수행할 경우 Merge와 다르게 Merge Commit이 생기지않음
- 하나의 브랜치에서 작업한 것처럼 보이므로 히스토리를 간결하게 하고 싶을 때 사용함
- merge commit을 만들지 않아 히스토리가 깔끔해짐
4. Squash Merge
- 여러 커밋을 하나의 커밋으로 만들어줌
$ git rebase -i [CommitID]
- rebase에 -i 옵션 이용해야 함
- pick과 squash를 사용하면 하나의 커밋이 아닌 원하는 커밋 수로 압축할 수 있음
- 정말 깔끔한 commit history를 만들 수 있지만 코드 에러 문제가 생길 경우 롤백이 불가능해짐
- 롤백 대비하여 작업완료한 브랜치를 삭제하면 안되고, 합쳐진 커밋 내용을 성실히 적어둬야함
내일 할 일
설계 작업하기