Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
Tags
- ERD 작성
- Q 클래스
- JoinColumn
- 스프링부트오류
- JPA주의사항
- Spring Spring boot 차이
- JPA
- queryDSL
- 1차캐시
- 최종 프로젝트
- jpa에러
- 인텔리제이
- git
- github
- jwt메서드
- Unsatisfied dependency
- Filter
- 복합키
- Error creating bean with name
- json
- REST API 규칙
- json gson 차이
- @IdClass
- uncheck Exception
- 스프링 부트 기능
- 스프링 부트 공식 문서
- 빈생성안됨
- spring서버
- jpa회원가입
- REST란
Archives
- Today
- Total
Everyday Dev System
git 브랜치 전략이란 본문
▶ git-flow 전략
▶ github-flow 전략
github-flow 전략은 git-flow 전략을 간소화시킨 전략이다.
평소에는 master랑 develop 브랜치 두개를 쓰다가,
새로운 기능을 개발해야 할 경우 feature 브랜치를 master 브랜치에서 생성합니다.
feature A, featureB 브랜치들을 1차 통합 단계인 develop 에 통합을 하게 된다.
그 develop 에서 통합 테스트를 진행한다.
배포용 release 브랜치를 만든다.
보통 배포를 할 때는 release 브랜치에서만 이뤄진다.
그런 후에 master에 마지막 최종 merge가 이뤄진다.
master까지 반영이 되었는데 버그 발견될 경우에는 hotfix 브랜치를 새로 생성하여
테스트하여 통과되면 develop에도 반영하고 master 브랜치에도 반영한다.
메인 브랜치와 보조 브랜치 두 종류로 나뉜다.
메인 브랜치는 master 와 develop이고,
보조 브랜치는 feature 브랜치이다.
feature나 release , hotfix 브랜치는 사용하지 않을 경우 지워줘야 한다.
master가 아닌 가지들은 master의 변동사항을 꾸준히 주시해야 한다.
대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게
더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
github flow는 master와 feature로만 이루어져 있다.
'내배캠 주요 학습 > 매일 공부' 카테고리의 다른 글
개발 인생 : 개발자 커뮤니티 회고 (0) | 2023.07.07 |
---|---|
WIL_0702 : 스프링 부트와 JPA (0) | 2023.07.02 |
의존성들 (0) | 2023.06.22 |
매니저님의 꿀팁 (0) | 2023.06.20 |
REST API 설계 규칙 (0) | 2023.06.16 |