# Content > [!info] 마틴 파울러의 리팩터링 2판에서의 용어 구분 > - 머지: 마스터를 로컬 브랜치로 병합하는 단방향 흐름 > - 병합 : pull & push로 마스터 브랜치에 영향을 주는 변경 마틴 파울러의 리팩터링 카탈로그를 따르면 코드베이스 전반에 걸쳐 자잘하게 수정이 발생하는 경우가 많다. 일반적으로 github flow나 기능별 브랜치 전략을 선택해 충돌이 발생할 수 있는 작업영역을 나누는 경우가 많지만, 애자일의 공동 소유원칙을 적용하거나 DDD를 실행하고 있다면 이런 회피 방법은 채택하지 말아야 한다. 아래는 기능별 브랜치의 대안의 목록이다. - 트렁크 기반 개발 (Trunk-Based Development) - 메인 브랜치(trunk/main)에 직접 커밋하거나 매우 짧은 수명의 브랜치 사용 - 작은 단위로 자주 커밋하고 통합하는 방식 - 리팩터링과 기능 개발을 작은 단위로 나누어 진행 - 피처 토글 (Feature Toggles) 사용 - 새로운 코드를 메인 브랜치에 계속 통합하되, 피처 플래그로 기능을 숨김 - 리팩터링된 코드와 기존 코드를 토글로 전환 가능하게 함 - 점진적인 롤아웃과 A/B 테스팅도 가능 - 스트랭글러 패턴 (Strangler Fig Pattern) - 리팩터링을 점진적으로 진행하면서 새 코드와 기존 코드를 공존시킴 - 점진적으로 새 구현으로 전환하고 오래된 코드를 제거 - 작은 단위의 리팩터링 - 큰 리팩터링을 여러 개의 작은 리팩터링으로 나눔 - 각각의 리팩터링이 독립적으로 안전하게 수행될 수 있도록 함 - 테스트를 통한 안전성 확보 - 지속적 통합 (Continuous Integration) - 하루에도 여러 번 메인 브랜치에 통합 - 자동화된 테스트로 빠른 피드백 - 문제 발생 시 빠른 발견과 수정 우선, 기능별 브랜치 전략을 유지하면서 적용할 수 있는 보충안으로는 CI를 적용하는 방법이 있다. 이 방식은 충돌 가능성을 낮추지는 못하지만 충돌 규모를 줄여줌으로써 개별 개발자가 병합을 좀 더 수월하게 수행할 수 있도록 돕는다. 리팩터링에 따른 충돌 빈도의 차이는 없지만 CI와 공동 소유원칙을 적용중인 팀은 페어 프로그래밍도 도입했을 가능성이 높으므로 별 문제는 없을 것이다. 트렁크 기반 개발은 프로젝트 특성에 따라 제한적인 적용을, 스트랭글러 패턴은 팀 전체가 스트랭글러 패턴과 도메인에 대해 어느 정도 이해하고 있는 환경이 나을 것이다. 피쳐 토글은 별도의 문서나 주석 형태로 글을 남기는 편이 좋다. 모든 대안에 공통적으로 적용할 수 있는 원칙은 아래와 같다. - 변경사항을 작게 유지 - 자주 통합 - 자동화된 테스트로 안전성 확보 - 점진적인 변경으로 리스크 관리 - - - ## Reference - [[리팩터링의 계층]] - [[계획 게임]] - - -