머가필요해

Git에 대해서 공부하다보면, 조금 답답한 것 중 하나가 용어 정리를 해주지를 않는다는 점이다.
그런 것 중 하나가 바로 [ Fast-Forward ]라는 용어다.


이 블로그에 포스팅하고 있는 내용들 모두 마찬가지이지만,
특히 이번 블로그는 절대적으로 개인적인 의견과 함께 개인적으로 정리한 내용이다.
즉, 완전 거짓말일 수 있다는 말이다. 꼭 참고하길 바란다!!! (책임지지 않아요~)



1. 합치자고~

     - Git에서 이루어지는 merge 방법은 다음의 세가지 타입이 있다.
          ▷ 3-way merge
          ▷ fast-forward merge
          ▷ cherry-pick

     - 명령어로 따지면 다음 3가지 방법이 있다.
          ▷ merge
          ▷ rebase
          ▷ cherry-pick



2. 명령어와 방식의 구분

     - 각 명령어와 merge 방식의 관계는 다음과 같다.

	merge	rebase	cherry-pick
3-way merge	O	X	X
fast-forward merge	O	O	X
cherry-pick	X	X	O

 

Git의 가장 큰 장점인 자유로운 branch, 그 branch의 자유로운 사용의 최종 종착지는 바로 merge다.
즉, branch를 생성해서 자유롭게 작업하다가 그 결과가 쓸만해지면 master에 merge하는 것이 일반적인 경우이다.
그런데, 바로 이 자유로운 branch 때문에 repository 내부가 지저분해질 우려가 다분히 많다.

많은 사용자가 달라붙어서 작업을 하다보면 별의 별 희한한 개발습관을 보여주는 개발자가 꼭 존재하고,
이러한 개발자들로 인해서 master branch가 바보가 되어버리는 경우도 종종 발생한다.

문제는 이러한 경우로 인해서 Git의 안전성을 의심받기까지 한다는 점이다.

제대로 이해를 하고 사용하는 사용자들은 무관하지만,
어설픈 지식으로 말도 안되는 행위를 과감히 행하는 개발자들이 문제가 되는 것인데...

그렇다 하더라도 무조건 그 책임을 무지한 개발자 탓으로 할 수는 없다.

그 부분을 해결하는 것은 해당 repository를 운영하는 담당자의 몫이며,
그러한 부분에 대한 분명한 프로세스 또는 가이드를 제시해주어야 한다.

이런 막중한 책임과 임무를 가진 관리자에게 merge 명령어 외에도 또 하나의 무기를 Git에서 제공해주고 있다.
그것이 바로 rebase 이다.


1. branch

    - rebase를 설명해보기 위해서 상황을 준비해보자.

     - 우선 branch 하나를 만들어 주고,

     - 파일 하나 수정해서 commit까지 해보자.




2. before log

     - rebase 하기 전에 현재 log를 살펴보고 시작하자.

3. rebase

     - 우선은 'hotfix branch'의 log 부터 확인하고,

     - merge 대신에 우리모두 rebase 하자!

     - 어?! 뭔가 rebase가 정상적으로 이루어지지 않은 것 같다!

     - 바로 뒤에 설명을 하겠지만, 위와 같은 상황에서는 rebase를 할 것이 없다.

     - master branch에서 commit 하나 추가해보자.

     - 위 그림과 같이 A commit에서 각 branch 별로 분기를 하도록 한 것이다.

     - 다시 rebase 해보자.
     - 그런데, log를 보면 이전 master branch에서 작업한 내용까지만 있다. 뭐지?!
     - rebase 후 해야하는 것이 fast-forward 해줘야 한다.

     - 어?! 뭔가 이상하지 않은가?
     - merge의 다른 방법이 rebase라는데, rebase를 하고도 결국 다시 merge를 해야하다니???

     - 일단, rebase를 하고 나면 아래와 같은 상태가 된다.

     - 뭔가 다른 점을 찾았는지.....?!
     - A에서 분기를 했던 hotfix branch의 B commit이 사라지고,
       master branch의 C commit 뒤에 새로운 B` commit이 생겼다.

     - rebase는 branch로 인한 commit의 분기를 한 줄로 다시 줄을 세운다. 그것도 새로운 commit을 만들어서...
     - 더불어 신기한 것은 기존의 commit은 사라진다(실제로 물리적으로 지워지는지는 나중에 살펴보겠다).

     - 그런데, 여기서 또 하나 잡아야 하는 포인트는 rebase 후에 master branch의 위치가 기존의 위치다.
     - hotfix branch의 내용을 master branch에 반영하기 위해서는 B` commit의 위치로 master branch가 가야한다.

     - 자료들을 보면 rebase 후 fast-forward 해주면 된다는데, fast-forward가 대체 뭔지....?! ㅋ~ 정답은 merge다.

     - 위와 그림과 같이 이루어진다.



앞에서 적었던 내용에 대해서 정정을 해야할 것 같다.

별도의 branch를 만들어서 작업을 하고 그것을 합치는 방법이 merge와 rebase의 두가지가 있다고 했는데,
이 말은 조금 틀린말 같다.

branch를 만들어서 작업한 내용을 합치는 방법은
바로 (즉시 merge)를 하는 방법과 (rebase 후 merge)를 하는 두 가지 방법이 있다.

rebase를 하는 이유는 commit을 깔끔하게 정리해서 일렬로 줄을 세워서 정리를 해주는 것이다.
즉, branch의 남발로 인해서 commit들이 꼬일 우려가 있는 상황에서 단순화 할 수 있는 좋은 수단이다.


다만, rebase를 사용하는 것은 작업하는 branch가 임시일 때 유용하다.
지속적으로 개발 branch를 유지하는 개발 프로세스를 사용한다면 rebase는 적합하지 않다.



오늘 두산이 KIA의 윤석민을 잡았다~!!! ^^
즐거운 하루~~~~ 인데, 포스팅을 하다보니 새벽 1시가 다가오네.... ㅠㅠ

모두 파이팅~!!!