git은 스냅샷을 찍는 방식으로 구분하여 수정여부를 추가/삭제하기 때문에 브런치 merge(병합) 전에는 merge로 인해 변경되는 브런치 관계와 파일들의 상태를 생각해야 한다. 또 원격 저장소에 저장을 함께 하는 경우 진행과정 중 실수로 인한 충돌이 없도록 순차적으로 차근차근 확인하면서 연결하는 것도 중요하다.
때문에 merge전 반드시 git branch -r, git branch -a, remote --v, log --branches --graph, git diff나 cat등을 이용해 text를 확인하거나, 다각도로 변경 요소들의 상황을 다시 점검 후에 진행하는 것이 필요하다.
잘못 merge되거나, push까지 진행이 된 상황이면 그 문제들이 팀까지 퍼져나가 팀원간 전체 작업에 큰 영향을 끼치게 될 것이다(대 재앙 생성 가능...)
--patch를 활용하거나 format-patch, checkout --patch 등을 이용, 추가적인 e 명령을 사용하면 브랜치 병합 전에 원하는 파일을 단계별로 상세히 나눠서 자르는 식의 수정을 마친 후 충돌이 없게끔 merge하는 것도 가능하다(그치만 변경하려는 파일이 너무 많거나 변경사항이 많다면 이 수작업은 엄청난 투머치가 되므로 다른 방법을 사용하는 것을 추천....)
브랜치 병합에는 3가지 종류가 있다
1. Merge
Fast-Forward, 3-Way-Merge를 많이 사용
fast-foward가 사용 가능한 경우라면 깃이 이전의 이력을 이용해 손쉽게 병합할 수 있으나
전체적인 작업/브랜치 관리를 위해서는 merge가 가진 옵션을 사용하는 것도 좋은 방법이 된다
fast-foward상태라 하더라도 Non-Fast-Forward 상태로 적용하는 옵션도 있다(--no-ff)
2. Rebase Merge
일반적인 Merge는 변경 내용의 이력들이 그대로 남기 때문에 프로젝트의 규모가 커질수록 복잡해진다.
Rebase를 이용하면 브랜치의 이력을 이동시킬 수 있어 merge시 이력은 단순해지지만, 원래의 커밋 이력이 변경된다. 따라서 정확한 이력을 남겨야 할 필요가 있는 브랜치 병합에서는 사용하면 안된다.
그러므로 상황에 맞춰 Rebase를 활용한 merge를 이용하는 것이 좋다.
3. Squash Merge
여러 개의 커밋을 하나로 합치고 다른 브랜치와 병합하는 방식
작업한 commit이 많아 지저분하다면 Squash를 이용해 Merge하는 것이 좋다. Squash를 사용해 원하는 만큼의 commit들을 통합시킨 후 merge하면 내가 원하는 커밋 수로 압축된 병합이 적용된다
'More than TIL > GIT' 카테고리의 다른 글
| git pull Already up to date (0) | 2022.04.13 |
|---|