Git Pull Requests의 Merge 전략

Pull Requests

 

Merge

브랜치에서 작업한 내용을 메인 브랜치로 통합하는 가장 일반적인 방법

 

장점:

• 이전의 커밋 히스토리를 그대로 유지하기 때문에 변경 이력이 정확하게 기록된다.
• 다른 브랜치에서 동시에 작업하는 경우 충돌이 발생할 수 있지만, 이를 강제하여 코드의 일관성을 유지할 수 있다.

단점:

• Branch가 많아지고 Commit도 많아지면 Commit History가 복잡해질 수 있다.

 

Squash Merge

여러 개의 Commit을 하나로 합친 후 Merge하는 전략

 

장점:

• Merge Commit이 남기 때문에 Merge가 되었다는 사실을 알 수 있다.
• Commit History가 깔끔해진다.

단점: Merge된 브랜치의 변경 내역이 하나의 Commit으로만 남기 때문에 어떠한 과정으로 변경되었는지에 대한 History는 알 수 없다.

 

Rebase Merge

Rebase 기능을 사용해 브랜치를 Merge하는 전략

 

장점: 변경 이력을 선형으로 만들어 Commit History를 깔끔하게 유지한다.

단점: Merge Commit이 남지 않기 때문에 병합시킨 브랜치가 언제 병합 되었는지의 시점을 알 수 없다. (태깅에 더 신경 써야한다.)

 

 

결론:

실무에서는 Merge 전략이 가장 일반적으로 사용된다.
Merge 전략은 다른 브랜치에서 동시에 작업하는 경우 충돌을 해결하도록 강제할 수 있기 때문에, 팀에서 함께 작업하는 경우 충돌을 예방하고 코드의 일관성을 유지하는 데 큰 도움이 된다.

또한, Merge 전략은 커밋 히스토리를 그대로 유지하기 때문에 변경 이력이 정확하게 기록되며, 나중에 코드 변경을 추적하거나 문제를 해결할 때 유용하다.
따라서 대부분의 Git 사용자들은 Merge 전략을 기본으로 사용하며, 다른 전략들은 특정 상황에서만 사용한다.