차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- git:merge [2025/04/15 10:05] – 바깥 편집 127.0.0.1
+++ git:merge [2025/06/10 04:53] (현재) – [커밋 되돌리기] taekgu
@@ 줄 1: / 줄 1: @@
-====== Merge ======
+====== Merge (git merge) ======
 [[https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-%EA%B3%A0%EA%B8%89-Merge#_advanced_merging|고급Merge]]
-git merge의 복잡성
+하나의 branch에 다른 branch를 합치는 작업을 말한다.
+===== 브랜치를 합치는 여러 방법 =====
+==== 1. 3-Way Merge =====
+각 브랜치에 커밋이 있는 경우, git merge 명령어를 사용하면 두 브랜치의 코드를 합쳐서 새로운 커밋을 만들어주는 방식이 바로 3-Way Merge 방식입니다. 이 경우 같은 파일에 대해 다른 변경사항이 있을 경우 "충돌"이 발생하게 됩니다. 위의 방법대로 해당 파일의 충돌을 해결한 후 커밋을 하면 됩니다.
+==== 2. Fast-Forward Merge =====
+기준이 되는 브랜치(Main, Master, etc)에는 신규 커밋이 존재하지 않고 다른 브랜치에만 커밋이 존재할 때 브랜치 병합을 하는 경우, 자동으로 Fast-Forward Merge가 이루어집니다. 새로운 커밋이 생기지 않고 HEAD의 위치만 변하게 됩니다.
+==== 3. Rebase & Merge =====
+rebase(재배치)는 브랜치가 뻗어나온 기준점을 변경하는 것을 말합니다. rebase를 이용하여 새로운 브랜치의 기준점을 최근 커밋으로 옮긴 후 Fast-Forward Merge를 하는 것입니다. 이러한 방식으로 병합을 하면 "병합 커밋을 보지 않는다"는 장점이 있습니다. 하나의 브랜치에서 작업한 것과 같은 효과를 얻을 수 있기에 커밋 로그가 깔끔해집니다. 다만, rebase는 브랜치끼리의 작업 내역 차이가 많은 경우 충돌이 많이 발생할 수 있습니다.
+<code bash>
+# practice1 브랜치로 이동
+git switch practice1
+# practice1 브랜치를 main 브랜치로 재배치
+git rebase main
+# main 브랜치로 이동
+git switch main
+# main 브랜치에서 practice1 브랜치를 fast-forward merge하기
+git merge practice1
+</code>
+==== 4.Squash & Merge ====
+-Way Merge의 가장 큰 단점은 병합한 브랜치들의 커밋 내역까지 모두 보여지기에 커밋 로그가 매우 복잡하고 지저분해진다는 것입니다. Squash and Merge 방식은 병합할 브랜치에 있는 모든 커밋들을 하나의 커밋으로 만든 후, 기준이 되는 브랜치에 추가하는 방식으로 병합합니다. 커밋 로그가 매우 깔끔해진다는 장점이 있으나, 병합할 브랜치의 모든 커밋 이력이 사라져버린다는 단점이 있습니다.
+<code bash>
+# main 브랜치로 이동
+git switch main
+# --squash 옵션을 통한 병합
+git merge --squash 브랜치명
+# 기존의 커밋들을 하나로 합친 새로운 커밋
+git commit -m "메세지"
+</code>
+===== 충돌 (Merge Conflict) =====
+그러나 브랜치를 서로 합칠 때는 주의해야할 것이 있습니다. 바로 "충돌"입니다. 충돌(Merge Conflict)이란 서로 다른 브랜치에서 같은 파일이나, 같은 줄을 수정하고 병합할 때 부딪히는 현상을 말합니다.
+아래의 사진이 바로 충돌이 일어난 상황입니다. 같은 파일에서 master 브랜치와 practcie1 브랜치의 코드가 다른데 병합을 시도하였기에 다음과 같이 충돌이 발생한 것입니다.
+해결방법은 간단합니다. <<<<<< / >>>>>> / ===== 같은 쓸데없는 것들 지운 후, 자신이 남기고자 하는 코드를 남기고 git add 파일명, git commit -m "메세지" 를 입력하여 새로운 커밋을 생성하면 됩니다. 그러면 충돌이 해결되고 브랜치도 정상적으로 잘 합쳐지게 됩니다.
+==== 머지 작업 취소 ====
+머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아갈 수 있다.
+<code bash>
+git merge --abort
+</code>
-기본머지
-  git merge dev
-머지취소
-  git merge --abort
 git merge --abort 명령은 Merge 하기 전으로 되돌린다. 완전히 뒤로 되돌리지 못하는 유일한 경우는 Merge 전에 워킹 디렉토리에서 Stash 하지 않았거나 커밋하지 않은 파일이 존재하고 있었을 때뿐이다. 그 외에는 잘 돌아간다.
 Merge 후의 결과를 Merge 하기 전의 브랜치와 비교하려면, 다시 말해 무엇이 합쳐졌는지 알려면 **git diff --ours** 명령을 실행한다.
-  git diff --ours
-===== Merge 되돌리기 =====
+<code bash>
+git diff --ours
+</code>
+==== Merge 되돌리기 ====
 지금까지 Merge 하는 방법을 배웠으나 Merge 할 때 실수할 수도 있다. Git에서는 실수해도 된다. 실수해도 (대부분 간단하게) 되돌릴 수 있다.
@@ 줄 36: / 줄 90: @@
 브랜치를 옮기는 것을 할 수 없는 경우는 모든 변경사항을 취소하는 새로운 커밋을 만들 수도 있다. Git에서 이 기능을 “revert” 라고 부른다. 지금의 경우엔 아래처럼 실행한다.
-  $ git revert -m 1 HEAD
+<code bash>
+$ git revert -m 1 HEAD
   [master b1d8379] Revert "Merge branch 'topic'"
+</code>
 -m 1 옵션은 부모가 보호되어야 하는 “mainline” 이라는 것을 나타낸다. HEAD 로 Merge를 했을 때(git merge topic1) Merge 커밋은 두 개의 부모 커밋을 가진다. 첫 번째 부모 커밋은 HEAD (C6)이고 두 번째 부모 커밋은 Merge 대상 브랜치(C4)이다. 두 번째 부모 커밋(C4)에서 받아온 모든 변경사항을 되돌리고 첫 번째 부모(C6)로부터 받아온 변경사항은 남겨두고자 하는 상황이다.
 새로 만든 커밋 ^M 은 C6 과 내용이 완전히 똑같다. 잘못 Merge 한 커밋까지 HEAD 의 히스토리에서 볼 수 있다는 것 말고는 Merge 하지 않은 것과 같다. topic 브랜치를 master 브랜치에 다시 Merge 하면 Git은 아래와 같이 어리둥절해한다.
-  $ git merge topic
+<code bash>
+$ git merge topic
   Already up-to-date.
+</code>
 이미 Merge 했던 topic 브랜치에는 더는 master 브랜치로 Merge 할 내용이 없다. 상황을 더 혼란스럽게 하는 경우는 topic 에서 뭔가 더 일을 하고 다시 Merge를 하는 경우이다. Git은 Merge 이후에 새로 만들어진 커밋만 가져온다.
 이러면 가장 좋은 방법은 되돌렸던 Merge 커밋을 다시 되돌리는 것이다. 이후에 추가한 내용을 새 Merge 커밋으로 만드는 게 좋다.
-  $ git revert ^M
+<code bash>
+$ git revert ^M
   [master 09f0126] Revert "Revert "Merge branch 'topic'""
-  $ git merge topic
+$ git merge topic
+</code>

GaramX

사용자 도구

사이트 도구

차이

문서 도구