<div id="readability-page-1" class="page"><div><h3 id="git-merge">git merge</h3>
<blockquote>
💡 Merge는 "내가 현재 있는 브랜치에 다른 브랜치를 합치는 것"이다.
<pre><code>git checkout feature/board
git merge develop</code></pre>
"<code>develop</code>의 내용을 <code>feature/board</code> 브랜치로 가져오겠다" 는 의미이다.
</blockquote>
<pre><code>git checkout main
git merge develop</code></pre>
<blockquote>
기능 개발이 끝난 후, develop 브랜치에 여러 기능이 모였다면 
이제 그것을 배포용(main)에 합치는 것 
즉, 이번 릴리스를 main에 반영하려고, develop의 모든 변경을 가져오는 것이다.
</blockquote>
<h3 id="git-rebase">git rebase</h3>
<blockquote>
<code>merge</code>는 "히스토리 그대로 보존", <code>rebase</code>는 "히스토리 깔끔하게 정리"
</blockquote>
<img src="https://velog.velcdn.com/images/psj0810/post/fba5d848-52b3-487a-8493-cdf2067c751a/image.png">
<blockquote>
✅ 시작 상황 (공통 전제)
<pre><code>A -- B -- C ← main
 \
 D -- E ← feature</code></pre>
<ul>
<li><code>A, B, C</code>: main 브랜치 커밋</li>
<li><code>D, E</code>: feature 브랜치 커밋</li>
</ul>
</blockquote>
이제 <code>feature</code> 브랜치를 <code>main</code>에 병합하고 싶다고 가정하자.
<hr>
<blockquote>
git merge (히스토리 보존, merge 커밋 생성)
<pre><code>git checkout main
git merge feature</code></pre>
📈 결과 히스토리:
<pre><code>A -- B -- C ----------- G ← main
 \ /
 D -- E ----- ← feature

(G: merge commit)</code></pre>
<ul>
<li><code>G</code>: merge 커밋 (자동 생성됨)</li>
<li>브랜치 병합 흔적이 남고, 커밋 흐름이 비선형(트리 구조) 으로 보임</li>
<li>히스토리 보존, 충돌 시점 명확</li>
</ul>
</blockquote>
<hr>
<blockquote>
git rebase (히스토리 정리, 깔끔하게 만들기)
<pre><code>git checkout feature
git rebase main</code></pre>
📈 결과 히스토리:
<pre><code>A -- B -- C -- D' -- E' ← feature
 ↑
 (replayed)</code></pre>
<ul>
<li><code>D', E'</code>: 기존 <code>D, E</code>를 새로 생성된 커밋으로 다시 쌓은 것 (커밋 ID 달라짐)</li>
<li>이후 병합하면:</li>
</ul>
<pre><code>git checkout main
git merge feature</code></pre>
결과:
<pre><code>A -- B -- C -- D' -- E' ← main, feature</code></pre>
✨ 선형 히스토리 완성! 
더 깔끔하고 분석/리뷰가 쉬움
</blockquote>
<img src="https://velog.velcdn.com/images/psj0810/post/dc28cb6a-1cd0-4f0d-bf47-b8463d3876ee/image.png">
🔍 다이어그램 설명
🔁 Merge (병합)
<ul>
<li><code>D</code>, <code>E</code>: feature 브랜치에서 작업한 커밋</li>
<li><code>G</code>: main 브랜치에서 <code>feature</code>를 병합하면서 생긴 merge 커밋</li>
<li>히스토리가 분기 + 병합 형태로 유지됨 (히스토리 복잡하지만 보존됨)</li>
</ul>
🔀 Rebase
<ul>
<li><code>D'</code>, <code>E'</code>: feature 브랜치의 커밋이 main 브랜치 끝에 다시 쌓인 것 (새 커밋처럼 생성됨)</li>
<li>히스토리가 일렬로 깔끔하게 정리됨</li>
</ul></div></div>

psj.log

git merge
💡 Merge는 "내가 현재 있는 브랜치에 다른 브랜치를 합치는 것"이다.
git checkout feature/board
git merge develop
"develop의 내용을 feature/board 브랜치로 가져오겠다" 는 의미이다.
git checkout main
git merge develop
기능 개발이 끝난 후, develop 브랜치에 여러 기능이 모였다면
이제 그것을 배포용(main)에 합치는 것
즉, 이번 릴리스를 main에 반영하려고, develop의 모든 변경을 가져오는 것이다.
git rebase
merge는 "히스토리 그대로 보존", rebase는 "히스토리 깔끔하게 정리"
✅ 시작 상황 (공통 전제)
A -- B -- C     ← main
       \
        D -- E  ← feature
A, B, C: main 브랜치 커밋
D, E: feature 브랜치 커밋
이제 feature 브랜치를 main에 병합하고 싶다고 가정하자.
git merge (히스토리 보존, merge 커밋 생성)
git checkout main
git merge feature
📈 결과 히스토리:
A -- B -- C ----------- G      ← main
       \             /
        D -- E -----         ← feature
>
(G: merge commit)
G: merge 커밋 (자동 생성됨)
브랜치 병합 흔적이 남고, 커밋 흐름이 비선형(트리 구조) 으로 보임
히스토리 보존, 충돌 시점 명확
git rebase (히스토리 정리, 깔끔하게 만들기)
git checkout feature
git rebase main
📈 결과 히스토리:
A -- B -- C -- D' -- E'     ← feature
                          ↑
                       (replayed)
D', E': 기존 D, E를 새로 생성된 커밋으로 다시 쌓은 것 (커밋 ID 달라짐)
이후 병합하면:
git checkout main
git merge feature
A -- B -- C -- D' -- E'     ← main, feature
✨ 선형 히스토리 완성!
더 깔끔하고 분석/리뷰가 쉬움
🔍 다이어그램 설명
🔁 Merge (병합)
D, E: feature 브랜치에서 작업한 커밋
G: main 브랜치에서 feature를 병합하면서 생긴 merge 커밋
히스토리가 분기 + 병합 형태로 유지됨 (히스토리 복잡하지만 보존됨)
🔀 Rebase
D', E': feature 브랜치의 커밋이 main 브랜치 끝에 다시 쌓인 것 (새 커밋처럼 생성됨)
히스토리가 일렬로 깔끔하게 정리됨

git 명령어 제대로 공부하기

댓글