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 | 29 | 30 | 31 |
Tags
- 로그백
- DDD
- 공통기술
- 사면초가
- 단위테스트
- JPA
- TDD
- 클린아키텍처
- 공통규약
- SEQUENCE
- model
- SpringLegacy
- MVC
- MVC요청플로우
- 전전긍긍
- AOP
- 문제선택근거
- 디스크i/o
- springsecurity
- 이벤트핸들러등록
- JDBC
- string
- 설정세팅
- Transaction
- OOP
- 냄새라도
- 커뮤니티서버
- 이벤트핸들러this
- Ajax
- index
Archives
- Today
- Total
개발이군고구마
[GIT] rebase 또는 merge main 으로 브랜치 현행화 본문
728x90
main에서 당겨받은 브랜치로 오랜동안 작업하다 보면,
다른 팀원들이 main에 merge한 최신사항들을 반영하지 못할 때가 많다.
브랜치 전략에 맞게 main 브랜치로 현행화를 시켜줘야하는데,
- 1. 현재 브랜치를 누군가와 함께 작업하는지 여부
- 2. 커밋 히스토리 (=해시코드)를 그대로 가져갈지의 여부
에 따라서 merge / rebase를 중 하나를 선택하여 현행화를 시키자.

[ 💁♀️ rebase가 좋아요]
나 혼자서 브랜치로 작업을 한다면 커밋 내역이 새로 생성되도 큰 문제가 되지 않고,
오히려 브랜치가 메인을 기준으로 깔끔해지는 장점이 있기 때문에 rebase도 무리가 없다.
[ 💁♀️ merge가 좋아요 ]
그러나 브랜치 하나를 두고 여러명이 commit 작업을 하는 경우, 한 팀원이 rebase로 커밋 내역을 새로 쌓게 되면
다른 팀원이 다시 pull 을 받고, 또 내역이 뒤틀리는 상황이 벌어질 수 있으니, 브랜치를 공유할 경우 merge로 현행화도 히스토리로 관리하는 것이 좋다.
✅ merge / rebase이든 충돌이 일어날 때 해소해주어야 하는 것은 동일하다.
'Cloud Deploy' 카테고리의 다른 글
| [멱살잡고 DevOps] 2. 배포 아키텍처 설계 (0) | 2025.07.15 |
|---|---|
| [멱살잡고 DevOps] 1. Docker Compose와 ECS (컨테이너의 분산 배포) (2) | 2025.07.14 |
| [우당탕탕 배포공부] 4. 과금 방지와 스프링단 설정 (리전/AZ와 .env) (1) | 2025.05.18 |
| [우당탕탕 배포공부] 3. AWS 세팅 2 - AWS RDS와 S3+CloudFront세팅 (0) | 2025.05.17 |
| [우당탕탕 배포공부] 2. AWS 세팅 1 - EC2와 ALB 세팅 (5) | 2025.05.16 |