이번 시간에는 거의 동일한 기능을 하지만, 약간의 차이가 있는 두가지 명령어를 알아보겠다. 사실, merge만으로 충분하지만, rebase도 만만치 않게 쓰이기 때문에 반드시 알아둬야 한다.
- git merge
=> 특정 branch를 master나 다른 branch로 흡수시켜주는 명령어
일단 merge를 자세하게 설명하기 위해, 상황 설정부터 해보자!!
나는 지금 development라는 branch의 수정사항을 master로 보내주고 싶다.
그런데, 이런 식으로 생각하는게 Git의 작동원리를 이해하는 데 훨씬 쉽다.
=> " master에서 development 파일들을 가져온다!! "
결론적으로 두 문장은 똑같은 말이지만, 실제 명령어를 이해하는데 있어서는 후자 쪽으로 생각하는게 좋다.
즉, (받는 쪽인) master가 development를 땡겨온다!!
=> 이게 git이 생각하는 merge의 실행방식이다.
이제 실제로 merge를 해보자!!
일단, merge를 해줄 때는 반드시 master branch로 돌아가서 실행해줘야된다.
좀 더 응용해보자면, branch A가 branch B를 받아오고 싶을 때는 반드시 땡겨주는 branch인 branch A로 이동한 후에, merge를 실행해야 한다.
밑에 그림을 예로 들면, branch dev로 이동한 후에, branch zero와 nero를 merge 해줘야 된다.
=> branch 안에 또다른 branch를 생성하거나 branch와 branch를 합치는 경우도 많으니 이 개념은 꼭 이해하자!!
실무에서는 master에서 충돌이 일어나는 것을 피하기 위해, dev라는 최종 branch에서 모든 충돌을 해결해준 뒤에, master로 넘겨주는 방식을 자주 쓴다고 한다.
=> 고객에게 배포되는 master 파일에 충돌이 일어나면, 어마어마한 클레임이 들어올테니 당연한 처사인듯 하다.
아무튼, 다시 돌아가서
master branch로 돌아간 뒤에 merge를 실행해줬다.
그런데, 오잉!!!!! 충돌이 생겼네!!
지금 상황에서 git status를 타입해보면,
code2.txt가 동시에 수정되있다는 것을 확인할 수 있다.
그리고 merge를 해주고 싶지 않다면, commit을 해주지 말고,
"git merge --abort"를 타입해주면 된다는 것을 확인할 수 있다.
이제 code2.txt를 확인해보자!!
development branch에서는 code2.txt의 첫번째 줄이 "제로초2개발개발개발"으로 수정해줬고,
master branch에서는
첫번째 줄을 "제로초2버그수정" 으로 수정해줬다.
충돌 이후, code2.txt에 들어가보면, git에서 이 부분을 표시해준다.
HEAD가 현재 파일을 땡겨오는 쪽( 받아오려는 쪽 )의 수정본 그리고
branch 이름이 기입 된 밑부분이 파일을 넘겨주려는 쪽의 수정본이다.
충돌된 부분은 당사자들끼리 잘 상의해서 수정하면 된다.
그리고 수정 이후에 다시 merge를 해주고 싶으면, git add 와 commit을 해주면 된다.
add와 commit을 따로 해주기 귀찮으면,
git commit -am " 내용 " 써서 한 번에 해줘도 되기는 한다.
commit 이후에는 충돌이 제거 됐기 때문에 자동적으로 merge가 완성 된다.
commit 이후에 다시 확인해보면,
merge가 성공적으로 됐음을 확인할 수 있다!!
여기까지 merge와 충돌 발생시에 해결법에 대해 정리해봤다.
이제는 git rebase에 관해서 알아보자!!
- git rebase
git rebase도 기능적인 측면에서 merge와 크게 다른 건 없지만,
아랫 부분처럼 지져분하게 잔가지들이 합쳐지는 걸 싫어하는 개발자들이 많이 쓴다. 사실, 아무리 둬져봐도 merge와 기능적으로 차이가 하나도 없다!! 그래서, 그냥 넘어가려다... rebase도 개발자들이 많이 쓰는 명령어 중에 하나이니, 알아둘 필요는 있다.
일단, rebase도 merge처럼 충돌이 발생하면, 그 부분을 먼저 해결해줘야 한다. 그리고 다음과 같은 상황이 오는데,
rebase를 하고 싶지 않다면, " git rebase --abort "
rebase를 진행하고 싶다면, git add 이후에 commit을 하는 게 아니라
" git rebase --continue "를 써줘야 한다.
그 뒤에 commit branch history를 확인해보면, merge와 다르게 일 자로 되있는 형태를 볼 수 있다.
[ TMI ] : merge와 rebase의 차이 그리고 rebase를 써야만 하는 경우가 있는지를 알아보던 중 Stackoverflow에서 개발자들끼리 갑을논박하면서, 이에 대해 답변을 한 링크를 공유한다.
그리고 이걸 읽는 게 귀찮은 분들을 위해서, 결론만 간단히 적어두겠다.
-
rebase는 언제 써야 하는가??
결론만, 간단히 말하자면, 깔끔해보이는 거 좋아하는 사람이 아니라면 merge만으로 모든 게 다 가능하다. -
merge와 rebase의 차이??
깔끔해보이는 거 외에 큰 차이가 없다. 만약에 C++를 공부했다면, rebase는 모든 branch들이 맨마지막 commit에 pointer로 지정되있다 정도의 차이인데... 구지 알 필요도 없는 것같다.
=> 그냥 전문적으로 들어가는 거 아니면, commit history에 보여지는 거 외에 차이가 없다고 결론 지어도 될 것같다!!
다음은 git 시리즈의 마지막 편인, git cherry-pick에 대해서 알아보겠다.
git merge 와 git rebase 끝!!!!!!!!
자료 출처 및 참고 자료
이번 블로그는 코드스테이츠의 강의 내용과 ZeroCho 블로그의 일부를 바탕으로 작성했으며, 그 어떠한 상업적 용도도 없음을 밝힌다.
https://www.zerocho.com/category/JavaScript
https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge
