git main에 머지하기

## git main에 머지하기

- 사전 상황
    - git을사용하여 여러명의 개발자가 개발을 진행중이다. main브랜치가 있고, 각 기능 개발시 별도의 브랜치를 사용하여야 한다.
    - 개발자1과 개발자2가 각각 기능1, 기능2를 개발 중이다.
- 상황 1
    - 개발자2가 기능2 개발을 완료하여 main 브랜치에 머지를 하려고한다. Merge, Rebase & Merge, Squash & Merge 중 어떤 방식을 사용해야할까
    - “히스토리는 무조건 깔끔해야 한다” : Squash & Merge를 사용
        - main 브랜치에는 자잘한 중간 커밋을 남길 이유가 없다.
        - “Feature: 로그인 구현” 과 같이 기능을 대표하는 한 줄의 커밋 만 남긴다.
    - 비교


| **방식** | **특징** | **장점** | **단점** |
| --- | --- | --- | --- |
| **Merge** (기본) | 모든 커밋과 병합 기록(Merge commit)을 남김 | 작업의 흐름(맥락)을 그대로 보존함 | 히스토리가 복잡해짐 (일명 '거미줄' 발생) |
| **Rebase & Merge** | 작업 브랜치의 기점을 main의 최신 상태로 옮김 | 히스토리가 한 줄로 깔끔하게 정리됨 | 충돌 해결이 까다로울 수 있고, 커밋 ID가 변경됨 |
| **Squash & Merge** | 여러 커밋을 **하나의 커밋**으로 합쳐서 합침 | main 히스토리가 매우 깨끗함 (기능당 커밋 1개) | 상세한 작업 과정(중간 기록)이 사라짐 |
- 상황 2
    - 개발자2가 기능2를 개발하여 main 브랜치에 머지를 완료하였다.(Squash & Merge). 이제 개발자1이 기능1을 개발완료하여 main에 머지할때 취해야할 조치는?
    - main 브랜치는 local에 항상 최신화 되어있다고 가정
        
        ```bash
        git pull main
        ```
        
    - 방법1) rebase로 처리
        - ‘기능1’ 브랜치에서 main브랜치에 대한 rebase 를 수행한다
            
            ```bash
            git checkout feature-1
            git rebase main
            ```
            
        - 충돌 발생시: 코드를 수정하고,
            
            ```bash
            git add .
            git rebase --continue
            ```
            
        - rebase후 push (—force옵션 사용)
            
            ```bash
            git push origin feature-1 --force
            ```
            
    - 방법2) merge로 처리
        - git pull orgin main 을 사용할 수 도 있지만 권장되지 않는다.
        
        ```bash
        git pull main
        ```
        
    - 원격 리파지토리(Github, Gitlab 등)에서 Squash & Merge 진행
        - 아래는 터미널 사용시
        
        ```bash
        git checkout main
        git merge --squash feature-1
        git commit -m "feat: 개발자 1의 기능 구현 완료"
        git push origin main
        ```
        
    - 상황2에서 merge가아닌 rebase를 사용하는 이유
        - main이 업데이트될 때마다 수시로 merge를하면, 나중에 히스코리 그래프를 읽기 힘들어진다
        - 이미 원격에 올린 브랜치를 Rebase를하면 소스가 꼬이기 쉽다 (브랜치는 공유하지 않는다는 원칙 필요)
    - 상황2에서 merge가 선호되는 이유
        - commit이 많이 쌓여있는 경우 충돌해결이 어려울 수 있다.
        - 어짜피 main 에는 Squash & Merge가 적용된다.