본문 바로가기

Git

git merge 에 관련된 실험 .merge 된 브랜치. 특정 커밋 시점으로 이동하는 법

728x90

git merge에 관해서 궁금했던 상황

내가 궁금했던 것은

우선 아래와 같은 상황(초록색 밑줄)일 때 그다음 branch의 쓰임과, merge에 관련된 궁금한 상황 3가지가 발생된다.

(기존 상태)

기존 master 브랜치에서 my.cpp소스 파일을 생성하고, 첫번째 커밋을 완료한 이후에

새로운 dev branch 를 생성해서, 그곳에서

my.cpp라는 소스파일 에 대해 특정한 작업을 진행한 후에

git checkout master

git merge dev

을 실행했다.

그리고 master 브랜치에서 작업을 2번 마친 상황이다. (위에서 3번째 사진)

 

(그런데 바로 아래 사진은 이후에 dev에서 다른 작업을 한 후에 또 checkout master 로 가서 merge 한 상태이다.)

 

 

  • 궁금했던것 첫번째. 위에 밑줄친 상황을 전제로.( 위에서 3번째 그림 시점)
    • merge dev 이후에 2번이나 master에 특정 작업-> commit 을 2번 반복한 후에 checkout dev 브랜치로 가서
    • 추가 작업을 할 경우 git log --graph는 어떻게 변하게 되는지, 이때의 HEAD는 (HEAD->master, dev)가 되는지 궁금했다

결과는 아래의 사진처럼 fast-foward는 되지 않는다. 하지만 graph의 그림이 신기하게 바뀌었다. 하지만 해쉬값 76955dcab~을 보면 단 한개만 dev브랜치에서 commit된 것을 알 수 있다.

 

여기서 내가 느낀점은 merge dev 이후 master에서 특정 작업을 이미 진행한 경우.

다시 checkout dev로 가서 my.cpp 파일에 대해서 작업을 하게 되는 것은 이전에 my.cpp에서 작업할 때 오류가 있었던 경우에 대한 작업이 아니면 굳이..? 언젠간 쓰이겠..  안 쓰일 것 같다. 그래프느 신기하다.

<특정 커밋 시점으로 이동하는 방법>

 

 

 

 

최근에 merge dev하기 이전 merge 상태, 내가 위에서 말한 커밋 상황인 master 커밋 시점으로 이동할 것이다.

d527d66878~~로 된 40자리의 16진수 해시 값 시점으로 이동할 것이다.

 

 

- 특정 커밋 시점으로 이동하는 방법

특정 커밋시점으로 이동하기 위해서는

git log --oneline을 통해 특정 commit왼쪽에 위치한 7자리 숫자를 확인해야 한다.

d527d66 으로 갈것이다.

 

 

동그라미 쳐진 왼쪽의 해시값을 복사 하고

git checkout d5a27d6

을 입력하면

 

특정 시점에 commit한 작업 상황과, git log graph를 볼 수 있다.

 

 

이 시점이다.

여기서 현 commit 시점으로 되돌아 가고 싶은 경우

git checkout -

를 입력하면 된다.

 

 

 

 

 

 

지금 커밋 상황이 내가 궁금한 질문을 하기 적합한 커밋 상황이다. 이상황을 전제로 3가지 궁금증을 해결할 것이다.

 

 

 

 

 

 

 

 

 

 

  • 궁금했던 것 두번째. 위에 밑줄친 상황을 전제로(위에 커밋 사진 상황)
    •  아래 사진과 같은 상황에서 하늘색 동그라미 까지 커밋을 한 상황이라 가정한다면. 

이 상황에서 master브랜치에 새로운 소스파일을 만든 후에

하늘색 동그라미 시점에서부터 위에 그려진 빨간색 처럼, 기존에 merge 되었던 develop브랜치를 재 활용해서 

그곳에서 작업을 한 후에 checkout master로 이동해서 merge develop을 하면 아래와같은 상황이 만들어지는지 궁금했는데,

애초에 그럴수 없다.

fast -forward 상태가 아니기 때문에.

그렇다면 기존 develop을 삭제하게 된다면 이전에 push했던 커밋 상태가 전부 사라질 것 같아 그러지 못하는 상황이다.

(신기하게도 3번째 실험에 의해 github저장소에 직접 브랜치를 삭제하지 않는 이상 develop기록은 남아있다.)

 

 

그전에 실험할 게 있다. 

  • 궁금했던것 세번째. 위에 밑줄친 전제 상황(3번째 사진) 에서 깃에 push 한 이후에 아래와 같은 사진을 만들기 위해 develop브랜치를 삭제한 이후에 추가적으로 master커밋 시점이 아래의 하늘색 commit 시점까지올 경우에 develop 브랜치를 또 만들면, 기존 github에 기록되어있던 develop브랜치의 상태는 어떻게 변화될 것인가? 
  • (이게 가장 궁금했다.)

우선 merge 된 develop 를 삭제한 이후에 동그라미 시점에 

git branch develop를 실행하고 , 기존처럼 develop에서 작업을 실행했다 그 결과 내가 바라던 그림이 나왔다.

하지만 여기서 궁금했던 것은 pull한 이후다. 

 

원래 나는 merge dev이후에 dev 브랜치도

git push origin dev를 하는데 . .오호라

github에 dev 브랜치에서도 여전히 삭제했던 dev 커밋에 대한 기록 또한 볼 수 있었다....

내가 궁금했던 것과 그에 대한 답을 찾은 것 같다.

 

추가로 궁금한게 생겼다.

위의 사진에서 merge dev 이후의 master에 2번의 커밋과정이 진행 된다면, 이때 beanch A라는 새로운 브랜치를 만들고 거기서 새 소스파일을 추가 후 merge를 한다면? (예를들어 다른 헤더파일에 대한 작업같은)

아예 그 A 브랜치와 같은 공간이 되어버린다. 애초에 A브랜치에서 작업 중일 때 checkout master로 나오면 뭐 할게없다. branch A에서 생성되서, 그이후 merge하면 fast-forward상태가 된다.

 

 

728x90