<div id="readability-page-1" class="page"><div>
      
        <header>
          
          
            <p> 




  2 minute read
</p>
          
        </header>
      

      <section itemprop="text">
        
        <h3 id="개요">개요</h3>
<p>여러 사람과 작업을 진행할 때, 형상관리 툴(Git)을 사용하여 체계적으로 코드를 통제하고 변경사항에 대해 히스토리가 생기고 쉽게 해당 히스토리에 대한 코드를 추적할 수 있습니다.<br>
프로젝트를 혼자 진행을 하면 코드 충돌에 대한 걱정이 없지만 두 명 이상의 개발자가 작업을 진행하다보면 충돌을 피할 수 는 없습니다.<br>
Git은 merge, rebase라는 키워드를 제공해주어 충돌 처리를 해결할 수 있도록 도와줍니다. 그럼 이 두 가지는 언제 어떻게 사용하면 좋을까요? <br>
merge와 rebase에 대해 알아봅시다.</p>

<h3 id="merge">merge</h3>
<p>버그 이슈를 처리하기 위해 master 브랜치에서 master-bug/#101이라는 브랜치를 생성했다고 가정합니다.<br>
코드를 수정하고 커밋 후 원격저장소로 push까지 완료했습니다. 아래와 같은 그림이 나옵니다.</p>
<div><pre><code><span>1628888 (HEAD -&gt;</span><span> </span>master-bug/#1, origin/master-bug/#1<span>)</span> master-bug/#1/코드 수정
<span>03acb2c (origin/master, origin/HEAD, master) 
</span></code></pre></div>
<p>HEAD는 master-bug/#1을 가리키고, master는 바로 아래에 있습니다.<br>
여기서 master와 병합하면 자신보다 최신 커밋과 병합하므로 fast-forward가 되지만, 팀원들과 일을 진행하면 항상 자신의 커밋이 master보다 최신일 수는 없습니다. 
아래와 같이 master-bug/#1 브랜치 기준으로 master 브랜치로 2개의 새 커밋이 반영되었습니다.</p>
<div><pre><code><span>4857a89 (origin/master, origin/HEAD, master) master/-/코드 수정2
dc1c778 master/-/코드 수정1
</span><span>1628888 (HEAD -&gt;</span><span> </span>master-bug/#1, origin/master-bug/#1<span>)</span> master-bug/#1/코드 수정
</code></pre></div>
<p>이제 master-bug/#1 브랜치를 master로 병합합니다.</p>
<div><pre><code><span>$</span><span> </span>git checkout master
<span>$</span><span> </span>git merge master-bug/#1
</code></pre></div>
<div><pre><code><span>26865d7 (HEAD -&gt;</span><span> </span>master, origin/master, origin/HEAD<span>)</span> Merge branch <span>'master-bug/#1'</span>
<span>4857a89 master/-/코드 수정2
dc1c778 master/-/코드 수정1
</span><span>1628888 (origin/master-bug/#</span>1, master-bug/#1<span>)</span> master-bug/#1/코드 수정
</code></pre></div>
<p>위 로그에서 첫 번째 줄에서 <strong>‘Merge branch ‘master-bug/#1’</strong> merge commit이 생성되는 걸 볼 수 있습니다.<br>
예시는 하나만 나오지만 여러 브랜치에서 master로 병합하는 횟수만큼 merge commit이 생성되어 히스토리를 추적하기에 어려움이 따를 수 있습니다.</p>

<h3 id="rebase">rebase</h3>
<p>이름 그대로 base를 재배치하는 것으로 현재 브랜치의 base가 된 커밋 시점을 변경하는 것을 의미합니다. 또한 merge commit이 생성되지 않고 병합을 원할 때(주의점에 merge commit이 생기는 경로있음), rebase 명령어를 사용할 수 있습니다.
성능 개선을 위한 브랜치인 master-task/performance 라는 브랜치를 생성했다고 가정합니다. 그 사이에 master 브랜치에 여러 버그가 수정되어 반영된 상태입니다.</p>
<div><pre><code><span>4b772c2 (origin/master, origin/HEAD, master) 10
e528980 9
</span><span>b76bcd3 (HEAD -&gt;</span><span> </span>master-task/performance, origin/master-task/performance<span>)</span> performance
</code></pre></div>
<p>HEAD는 master-task/performance이며, 해당 브랜치에 코드가 수정되어 커밋된 상태입니다. 그 위로 master에 2개의 커밋이 반영되었습니다.<br>
rebase는 현재 브랜치의 base가 되는 커밋을 변경해주는 것이므로 performance 브랜치를 최신 commit으로 맞추도록 rebase 명령어를 실행합니다.</p>

<div><pre><code><span>a22619e (HEAD -&gt;</span><span> </span>master-task/performance<span>)</span> performance
<span>4b772c2 (origin/master, origin/HEAD, master) 10
e528980 9
b76bcd3 (origin/master-task/performance) performance
</span></code></pre></div>
<p>위 로그에서 master-task/performance가 새 커밋이 하나 생기고 master의 상단으로 올라와 최신 커밋으로 변경된 것을 볼 수 있습니다.
이제 master에서 master-task/performance 브랜치를 병합해봅시다.</p>
<div><pre><code><span>$</span><span> </span>git merge master-task/performance
<span>Updating 4b772c2..a22619e
Fast-forward
 test.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
</span></code></pre></div>
<p>아래와 같이 fast-forword가 수행되는 것을 볼 수 있으며 로그 상에는 merge commit이 생성되지 않습니다.</p>
<div><pre><code><span>a22619e (origin/master, origin/HEAD, master, master-task/performance) performance
4b772c2 10
e528980 9
b76bcd3 (origin/master-task/performance) performance
</span></code></pre></div>

<h4 id="주의점">주의점</h4>
<ul>
  <li>rebase는 커밋 단위로 적용하기 때문에 merge처럼 충돌이 발생하면 한번만 처리하면 되지만 rebase는 commit마다 충돌처리를 해주어야 합니다.</li>
  <li>rebase 적용 후에 push를 시도한다면 아래와 같은 오류가 발생한다.
    <div><pre><code><span> ! [rejected]        master-task/performance -&gt;</span><span> </span>master-task/performance <span>(</span>non-fast-forward<span>)</span>
<span>error: failed to push some refs to 'https://github.com/rerewww/ttt.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
</span></code></pre></div>
    <p>pull을 받아서(merge commit이 생성됨) 다시 push를 하거나 <code>git push -f origin</code>  커맨드를 실행하는 방법이 있다.</p>
  </li>
</ul>

<h3 id="개인적인-결론">개인적인 결론</h3>
<p>rebase는 merge commit이 없어 history를 좀 더 깔끔하게 사용 할 수 있고 merge는 충돌처리에 대해서 한번만 수정하면 된다는 장점도 있고 여러 상황 중 master에 반영할 필요가 없는 브랜치인데 master의 최신 커밋을 반영하면서 작업을 해야한다면 rebase를 통해 꾸준하게 최신 브랜치를 유지할 수 있을 것 같습니다. 이렇게 서로 장단점이 존재하여 상황에 맞게 사용하면 좋을 것 같습니다.</p>

        
      </section>

      

      

      
  

    </div></div>

I Luv Console

개요
여러 사람과 작업을 진행할 때, 형상관리 툴(Git)을 사용하여 체계적으로 코드를 통제하고 변경사항에 대해 히스토리가 생기고 쉽게 해당 히스토리에 대한 코드를 추적할 수 있습니다.
merge
버그 이슈를 처리하기 위해 master 브랜치에서 master-bug/#101이라는 브랜치를 생성했다고 가정합니다.
1628888 (HEAD -> master-bug/#1, origin/master-bug/#1) master-bug/#1/코드 수정
03acb2c (origin/master, origin/HEAD, master) 
HEAD는 master-bug/#1을 가리키고, master는 바로 아래에 있습니다.
4857a89 (origin/master, origin/HEAD, master) master/-/코드 수정2
dc1c778 master/-/코드 수정1
1628888 (HEAD -> master-bug/#1, origin/master-bug/#1) master-bug/#1/코드 수정
이제 master-bug/#1 브랜치를 master로 병합합니다.
$ git checkout master
$ git merge master-bug/#1
26865d7 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'master-bug/#1'
4857a89 master/-/코드 수정2
dc1c778 master/-/코드 수정1
1628888 (origin/master-bug/#1, master-bug/#1) master-bug/#1/코드 수정
위 로그에서 첫 번째 줄에서 ‘Merge branch ‘master-bug/#1’ merge commit이 생성되는 걸 볼 수 있습니다.
rebase
이름 그대로 base를 재배치하는 것으로 현재 브랜치의 base가 된 커밋 시점을 변경하는 것을 의미합니다. 또한 merge commit이 생성되지 않고 병합을 원할 때(주의점에 merge commit이 생기는 경로있음), rebase 명령어를 사용할 수 있습니다.
성능 개선을 위한 브랜치인 master-task/performance 라는 브랜치를 생성했다고 가정합니다. 그 사이에 master 브랜치에 여러 버그가 수정되어 반영된 상태입니다.
4b772c2 (origin/master, origin/HEAD, master) 10
e528980 9
b76bcd3 (HEAD -> master-task/performance, origin/master-task/performance) performance
HEAD는 master-task/performance이며, 해당 브랜치에 코드가 수정되어 커밋된 상태입니다. 그 위로 master에 2개의 커밋이 반영되었습니다.
$ git rebase master
a22619e (HEAD -> master-task/performance) performance
4b772c2 (origin/master, origin/HEAD, master) 10
e528980 9
b76bcd3 (origin/master-task/performance) performance
위 로그에서 master-task/performance가 새 커밋이 하나 생기고 master의 상단으로 올라와 최신 커밋으로 변경된 것을 볼 수 있습니다.
이제 master에서 master-task/performance 브랜치를 병합해봅시다.
$ git merge master-task/performance
Updating 4b772c2..a22619e
Fast-forward
 test.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
아래와 같이 fast-forword가 수행되는 것을 볼 수 있으며 로그 상에는 merge commit이 생성되지 않습니다.
a22619e (origin/master, origin/HEAD, master, master-task/performance) performance
4b772c2 10
e528980 9
b76bcd3 (origin/master-task/performance) performance
주의점
rebase는 커밋 단위로 적용하기 때문에 merge처럼 충돌이 발생하면 한번만 처리하면 되지만 rebase는 commit마다 충돌처리를 해주어야 합니다.
rebase 적용 후에 push를 시도한다면 아래와 같은 오류가 발생한다.
    
 ! [rejected]        master-task/performance -> master-task/performance (non-fast-forward)
error: failed to push some refs to 'https://github.com/rerewww/ttt.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
    
pull을 받아서(merge commit이 생성됨) 다시 push를 하거나 git push -f origin  커맨드를 실행하는 방법이 있다.
개인적인 결론
rebase는 merge commit이 없어 history를 좀 더 깔끔하게 사용 할 수 있고 merge는 충돌처리에 대해서 한번만 수정하면 된다는 장점도 있고 여러 상황 중 master에 반영할 필요가 없는 브랜치인데 master의 최신 커밋을 반영하면서 작업을 해야한다면 rebase를 통해 꾸준하게 최신 브랜치를 유지할 수 있을 것 같습니다. 이렇게 서로 장단점이 존재하여 상황에 맞게 사용하면 좋을 것 같습니다.

Git merge와 rebase의 차이점을 알아보자

댓글