fast-forward, 3-way merge 비교

구분	Fast-forward Merge	3-way Merge
개념	두 브랜치가 같은 base 커밋을 가지고 있으며, 한 브랜치가 다른 브랜치보다 앞서 있음.	두 브랜치가 같은 base 커밋에서 분기되었지만, 서로 다른 커밋을 쌓아 독립적으로 발전됨.
새로운 병합 커밋	❌ 생성되지 않음	✅ 새로운 병합 커밋이 생성됨
작동 방식	뒤에 있는 브랜치(master)의 참조를 앞선 브랜치(dev1)로 단순 이동.	공통 조상(base)과 두 브랜치의 변경 사항을 비교하여 새로운 병합 커밋을 생성.
히스토리 형태	커밋이 한 줄로 깔끔하게 정리됨.	브랜치가 분기되었다가 병합된 기록이 남음.
충돌 발생 가능성	🚫 없음 (단순 참조 이동)	⚠ 가능 (같은 파일이 양쪽에서 수정되면 충돌 발생)
사용 조건	- 한 브랜치가 다른 브랜치보다 직접적인 후속(commit) 상태여야 함.	- 두 브랜치가 각각 독립적으로 commit을 쌓아온 경우.
예제 명령어	bash git merge dev1	bash git merge feature
장점	- 병합 커밋이 생성되지 않아 히스토리가 깨끗함.	- 분기와 병합 이력이 명확하여 협업 시 작업 흐름을 쉽게 파악 가능.
단점	- 분기 흔적이 남지 않아 히스토리 분석이 어려울 수 있음.	- 불필요한 병합 커밋이 많아지면 히스토리가 복잡해질 수 있음.

📌 정리

• Fast-forward Merge는 브랜치가 직선 관계에 있을 때 사용되며, 새로운 커밋 없이 브랜치 포인터만 이동.
• 3-way Merge는 서로 다른 커밋을 포함한 두 개의 브랜치를 병합할 때 사용되며, 새로운 병합 커밋을 생성.

merge 종류 설명 <- 여기서 자세하게 알아갈 수 있습니다.

cherry-pick

다른 브랜치의 원하는 커밋을 가져오는 방법입니다.

git cherry-pick (체리의 해시)

#ex)
git cherry-pick cadfd026adb861cef437c612fe4f3ef519bf256f  

git cherry-pick (다른 브랜치의 특정 커밋 가져오기)

특정 브랜치에서 원하는 커밋만 선택하여 현재 브랜치에 적용하는 방법.

git cherry-pick (커밋 해시)

예제

git cherry-pick cadfd026adb861cef437c612fe4f3ef519bf256f

해당 커밋(cadfd026adb861cef437c612fe4f3ef519bf256f)의 변경 사항을 현재 브랜치에 반영.

git rebase --onto (다른 브랜치에서 일부 커밋만 가져오기)

특정 브랜치의 일부 커밋만 다른 브랜치로 이동할 때 사용합니다.
일반적으로 사용할 일이 많지는 않지만, 특정 분기(branch)의 일부만 가져올 때 유용합니다.

git rebase --onto (도착 브랜치) (출발 브랜치) (이동할 브랜치)

예제

git rebase --onto main fruit citrus

fruit 브랜치에서 citrus 브랜치 이후의 커밋을 main 브랜치로 이동.

git merge --squash (다른 브랜치의 커밋을 묶어서 가져오기)

다른 브랜치의 여러 커밋을 하나의 커밋으로 합쳐서 가져오는 방법.
개별 커밋을 유지하지 않고 하나의 단일 커밋으로 적용.

git merge --squash (대상 브랜치)

예제

git merge --squash feature-branch

feature-branch 브랜치의 모든 변경 사항을 하나의 커밋으로 압축(squash)한 상태로 현재 브랜치에 적용.
이후 git commit을 실행하여 한 개의 커밋으로 저장.

git merge vs git merge --squash 차이점

구분	git merge	git merge --squash
작동 방식	두 브랜치를 병합하여 커밋 히스토리를 유지	병합 브랜치의 커밋을 하나로 합쳐서 적용
커밋 내역	원본 브랜치의 개별 커밋들이 그대로 유지됨	한 개의 커밋으로 압축됨
사용 목적	브랜치를 유지하면서 정식 병합할 때	여러 개의 작은 커밋을 하나로 정리할 때
병합 커밋 생성 여부	✅ 생성됨	❌ 생성되지 않음 (staged 상태)
병합 후 브랜치 상태	기존 브랜치가 유지됨	병합 후 기존 브랜치는 삭제해야 함

Git Flow - 협업을 위한 브랜치 전략

Git을 사용하는 주된 이유는 충돌 없이 효율적으로 협업하기 위해서입니다.
이러한 협업 방식을 체계적으로 정리한 Git Flow 모델이 있습니다.
📌 Git Flow 공식 문서

📌 Git Flow 브랜치 구조

Git Flow는 여러 개의 브랜치를 사용하여 개발 및 배포 프로세스를 관리하는 전략입니다.

브랜치	역할
master	최종 배포된 코드 (프로덕션)
develop	실제 개발이 진행되는 브랜치
feature	새로운 기능을 개발하는 브랜치 (develop에서 분기)
release	배포 전 테스트를 진행하는 브랜치
hotfix	프로덕션(배포된) 코드에서 긴급 수정이 필요한 경우 사용

🚀 Git Flow 브랜치 흐름

1. 개발 (develop)

• 모든 기능 개발은 develop 브랜치에서 이루어짐.
• 새로운 기능을 추가할 때는 feature 브랜치를 생성하여 개발 진행.

git checkout develop
git checkout -b feature/awesome-feature

기능 개발 완료 후 다시 develop에 병합.

2. 기능 테스트 (release)

개발이 완료되면 release 브랜치에서 테스트 진행.

git checkout develop
git checkout -b release/1.0.0

버그가 발견되면 수정 후 develop 브랜치에 반영.

3. 배포 (master)
   release 브랜치에서 문제가 없다면 tag를 추가하고 master에 병합.

git checkout master
git merge release/1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"

4. 긴급 수정 (hotfix)
   배포 후 심각한 버그가 발생하면 hotfix 브랜치를 생성하여 빠르게 수정.

git checkout master
git checkout -b hotfix/critical-bugfix

수정 후 master와 develop에 병합하여 동일한 문제가 다시 발생하지 않도록 방지.