GitHub_Merge 전략

1. Allow Merge Commits

Pull Request 에서 제안된 변경사항을 기존 코드에 통합할 때, 모든 개별 커밋을 유지하면서 별도의 병합 커밋을 생성합니다.

두 브랜치의 기록을 보존합니다. (모든 커밋과 메인 브랜치의 커밋 기록이 그대로 유지됩니다.)

 

장점 : 

기여자의 모든 커밋을 명확하게 보존하여 기여한 사람들과 정확한 기여 내용을 추적할 수 있습니다.

복잡한 프로젝트에서 변경 사항의 컨텍스트를 보존하는 데 유리합니다.

 

단점:

커밋 히스토리가 복잡해질 수 있으며 이는 이후에 히스토리를 이해하거나 문제를 디버깅할 때 어려움을 초래할 수 있습니다.

 

2. Allow Squash Merging

Pull Request의 모든 커밋을 단일 커밋으로 압축하여 메인 브랜치에 병합합니다.

변경사항을 하나의 커밋으로 요약하여 메인 브랜치에 추가합니다.

결과적으로 깔끔한 커밋 히스토리를 유지할 수 있습니다.

 

장점 : 

커밋 히스토리를 단순화하여 관리하기 쉽게 만듭니다.

여러 수정 사항이나 작은 커밋들을 하나로 요약하여 히스토리를 깨끗하게 유지할 수 있습니다.

 

단점 : 

기여자의 개별 커밋 정보가 손실됩니다.

특정 변경 사항에 대한 컨텍스트를 잃게 만들 수 있습니다.

 

 

3. Allow Rease Merging

Pull Request의 커밋을 메인 브랜치의 최상단에 재배치합니다.

브랜치의 커밋 히스토리를 메인 브랜치의 히스토리와 선형적으로 통합합니다.

모든 작업이 시간 순서대로 한 줄로 진행된 것처럼 보입니다.

 

장점 : 

히스토리가 선형적이므로 이해하기 쉽고 디버깅이나 히스토리 탐색이 용이합니다.

커밋 히스토리를 깨끗하게 유지하면서도 기여자의 개별 커밋을 보존할 수 있습니다.

 

단점 : 

재배치 과정에서 충돌이 발생할 수 있으며 해결하는 것이 복잡할 수 있습니다.

기존의 커밋 해시가 변경될 수 있어 이미 공유된 브랜치에서는 사용하기 어려울 수 있습니다.