DevOps/GIT

github#12 git rebase 기초

aliceintr 2020. 11. 26. 09:30
반응형

ref : www.perforce.com/blog/vcs/git-rebase-vs-merge-which-better

 

Git Rebase vs. Merge: Which Is Better? | Perforce Software

Compare Git rebase vs. Git merge to determine which is better.

www.perforce.com

 

 

 

git merge가 git rebase 보다 더 안전한 방법이다. 그러므로 깃에 어느정도 익숙해진 사람, 꼭 이 기능을 필요로 하는 사람에게만 사용을 권장한다.

 

 

 

git merge 와 git rebase 의 차이점에 대해 알아보자.

위의 링크에서는 이렇게 설명한다.

 


Git merge is a command that allows you to merge branches from Git.

Git rebase is a command that allows developers to integrate changes from one branch to another.


 

 

 

git merge 는 개인을 놓고 보았을 때 깃으로부터 브랜치를 합병한다는 의미가 강하다면 git rebase는 개발자들 즉 다수에 사람들의 소스코드를 한 브랜치에서 다른브랜치로 병합한다는 의미인것이다.

 

그래도 잘 모르겠다 정확한 차이를..더 자세히 읽어본다.


Git rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch. Unlike merging, rebasing flattens history. It transfers the completed work from one branch to another. In the process, unwanted history is eliminated.

Advocates of Git rebase like it because it simplifies their review process.


 

 

merge 가 병렬적인 구조로 기록이 남는것에 비해 rebase는 "flatten" 한다고 표현하고 있다. 그냥 1개의 패치로 만든다는 소리인데, 그 중에서 원하지 않는건 제거 할수도 있다.

 

 


Git rebase and merge both integrate changes from one branch into another. Where they differ is how it's done. Git rebase moves a feature branch into a master. Git merge adds a new commit, preserving the history.


 

 

두개가 기본적으로 다른 소스코드 작업물을 합친다는 의미는 가지고 있으나. 가장 큰 차이점은 rebase는 feature branch (본인이 작업하고 있는 브랜치라고 이해하면 쉬울듯) 을 master branch 에 흡수 시켜 버리는 반면, git merge 는 합쳐진 기록이 새로운 commit에 추가 되고 feature branch와 master branch 각각의 commit history 와 코드 업데이트 기록이 남아있다. 그러므로 feature branch만 가지고 있었던 commit ID 로 돌아갈 수 도있는 것같다.

 

 

 

두개의 장점과 어떤 경우에 사용해야 하는지 구분해보자면

  git rebase git merge
Benefit
  • Streamlines a potentially complex history.
  • Avoids merge commit “noise” in busy repos with busy branches.
  • Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams.
  • Simple and familiar.
  • Preserves complete history and chronological order.
  • Maintains the context of the branch.
어떤경우에 사용? working alone or on a small team working with a big team

 

 

 

 

도식화 해보면 아래와 같다.

Ref : https://hackernoon.com/git-merge-vs-rebase-whats-the-diff-76413c117333

 

 

 


공식화된 문서 : git-scm.com/book/en/v2/Git-Branching-Rebasing

 

Git - Rebasing

Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line: If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family. When you rebase stuf

git-scm.com


 

 

 

 

 

실제로 한번 rebase 를 해본다.

1. [Master Branch] commit 1

#현재 master branch에 있다. 
#파일하나 만들고 1번 commit을 한다. 
% vi test1.txt
% git add test1.txt
% git commit -m 1
[master (root-commit) 24ba255] 1
 1 file changed, 1 insertion(+)
 create mode 100644 test1.txt

2. [rb Branch] 브랜치를 바꾸고 commit을  R1 , R2 함

% git checkout -b rb
Switched to a new branch 'rb'
% git branch
  master
* rb
% git log
commit 24ba255494fade1a0604e6f4cead81d50aa3be97 (HEAD -> rb, master)
Author: aliceson89 <alice.son1109@gmail.com>
Date:   Wed Nov 25 18:13:14 2020 -0500

    1
% vi rebase.txt
% git add rebase.txt 
% git commit -m 'R1'
[rb 327b098] R1
 1 file changed, 1 insertion(+)
 create mode 100644 rebase.txt

% vi rebase.txt 
% git add rebase.txt
% git commit -m 'R2'
[rb 699ad04] R2
 1 file changed, 1 insertion(+), 1 deletion(-)

3. [rb Branch] 이제 log 를 확인해보면

#1
% git log --decorate --all --oneline --graph
* 24ba255 (HEAD -> rb, master) 1

#R1
% git log --decorate --all --oneline --graph
* 327b098 (HEAD -> rb) R1
* 24ba255 (master) 1

#R2
% git log --decorate --all --oneline --graph
* 699ad04 (HEAD -> rb) R2
* 327b098 R1
* 24ba255 (master) 1

4. [Master Branch] 이제는 master 브랜치로 옮기고 M1,M2 를 commit 해보자

% git checkout master
Switched to branch 'master'
% vi master.txt
% git add master.txt 
% git commit -m 'M1'
[master 328dfb2] M1
 1 file changed, 1 insertion(+)
 create mode 100644 master.txt

% vi master.txt
% git add master.txt 
% git commit -m 'M2'
[master dbdde2d] M2
 1 file changed, 1 insertion(+), 1 deletion(-)

5. [Master Branch] log 를 확인하자

#M1 Commit 
% git log --decorate --all --oneline --graph
* 328dfb2 (HEAD -> master) M1
| * 699ad04 (rb) R2
| * 327b098 R1
|/  
* 24ba255 1


#M2 Commit 
% git log --decorate --all --oneline --graph
* dbdde2d (HEAD -> master) M2
* 328dfb2 M1
| * 699ad04 (rb) R2
| * 327b098 R1
|/  
* 24ba255 1

 

6. [rb Branch] 이제 Branch를 rb로 바꾸고 master로 rebase한다.

% git checkout rb    
Switched to branch 'rb'

% git branch
  master
* rb

% git rebase master
Successfully rebased and updated refs/heads/rb.

7. [rb Branch] 이제 결과를 확인해보자

% git log --decorate --all --oneline --graph 
* 1d7b4ee (HEAD -> rb) R2
* 24584b4 R1
* dbdde2d (master) M2
* 328dfb2 M1
* 24ba255 1

일렬로 commit 이 rebase 된 것을 알 수 있다. 하지만 아직 master 브랜치는  M2에 머물러 있다.

 

8. [Master Branch]이제 master 를 최신버전으로 merge 하자

% git checkout master
Switched to branch 'master'

% git merge rb
Updating dbdde2d..1d7b4ee
Fast-forward
 rebase.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 rebase.txt

 

9. [Master Branch] 이제 log 확인을 해보자. 두 브랜치 다 R2 commit에 있는 것을 알 수 있다.

% git log --decorate --all --oneline --graph
* 1d7b4ee (HEAD -> master, rb) R2
* 24584b4 R1
* dbdde2d M2
* 328dfb2 M1
* 24ba255 1

 

여기까지가 기본적인 rebase 개념이다.

 

 

 

내용이 도움이 되셨다면 블로그 구독하기 부탁드리겠습니다.

* 이 글의 모든 저작권은 aliceintr에 있으며 무단 배포 및 사용은 자제해 주시기 바랍니다. *

반응형

'DevOps > GIT' 카테고리의 다른 글

github#14 git project 잘 관리하기  (0) 2020.11.26
github#13 git rebase 충돌해결  (0) 2020.11.26
github#11 git tag 와 branch 차이  (0) 2020.11.25
github#10 git push and pull  (0) 2020.11.24
github#9 git remote repository  (0) 2020.11.21