2020.09.13_git_merge

2020.09.13_git_merge_정리 노트

 

오늘은 git merge 에 대해서 정리하는 노트!

 

먼저 git merge란

 

 

git merge

란 협업해서 쓰는 방법으로 각자의 브랜치에서 작업을 하고 코드들을 한 브랜치에 병합하는 것. ( 보통 master에 merge )

 

사용하는 방법은 보통 master에서 전부 보기 때문에,

편의상 master 브랜치에서 내가 병합해줄 브랜치를 선택한다.

 

그냥 자기가 전체코드를 볼 브랜치에서 내가 작업해준 브랜치를 

git merge 작업 브랜치 하면 된다.

 

 

 

 

다시 위의 예를 들어서 저번 포스팅에서 썼던 브랜치를 이용해서 설명하면, ( 브랜치를 바꾸는 방법이나 저번 포스팅에 썼던 브랜치를 쓸거라서 이 포스팅 을 보고 오면 좋을듯! )

 

master branch에 가서 내가 만들어준 브랜치 practice를 git merge practice 를 통해 병합하면 된다.

 

 

이렇게 하게 되면, master에서 practice 브랜치에서 내가 수정해주거나 추가해준 코드들이 잘 병합된다. 

 

근데 여기서 종종 충돌이 일어나게 된다.

 

git conflict 

충돌이라는 뜻으로, 우리가 서로 다른 코드들을 수정해주었으면, 상관 없지만, 같은 코드들을 서로 모른채로 다르게 수정해준다면? 그러고 커밋을 해주게 되면 충돌이 일어나게 된다.

버전관리가 중요한 이유는, 다른 코드를 수정해주거나 같은 파일이라도 다른 부분을 수정해서 merge를 하게 되면 여기서는 자동으로 합쳐준다.

 

쨋든 이렇게 자동으로도 안되는 경우는 같은 파일에 같은 부분의 코드를 수정해주었는데 충돌이 난 경우겠지

 

그러면 우리 똑똑한 깃은 충돌이 났다고 알려주게 되는데, 예제로 ㄱㄱ

 

branch - practice

 

 

branch - master

 

 

 

이렇게 똑같은 위치의 코드를 각각 다르게 수정하고 commit을 해준다면?

 

 

 

짠잔 conflict 가 났다. 여기서 보면 자동으로 해결해주지 못했다. 이 경우는 실패가 뜨고 우리가 직접 conflict를 해결해주어야 한다.

 

 

 

이렇게 git status 를 이용해 충돌이 난 파일명을 확인하고 ( 나는 왜 이렇게 나오지.. ) 

 

나는 파일명이 이상해서 vs 코드로 가서

 

 

 

여기를 보면 이렇게 뜨게 된다. 해당 파일로 가서 보게 되면,

 

 

 

이렇게 깃이 충돌이 난 부분을 가르쳐 주게 된다. HEAD 부분부터 ======== 부분까지는 master 부분의 코드를 

 

>>>>>>브랜치명 까지는 merge 하려는 브랜치명의 코드를 보여준다 . 

 

 

 

 

그래서 충돌이 난 부분의 이 옵션들을 보면, 이런 옵션들을 버튼으로 제공해주게 되는데, 

 

첫번째부터 current change ( 여기서는 master ) 부분의 코드로 바꿀 것인지,

incoming change ( 여기서는 practice ) 부분의 코드로 바꿀 것인지,

둘의 코드를 모두 써줄 것인지 ( 여기서는 print라서 상관없지만, 기능에 대해서는 꼬일 수 있으니 되도록 선택 ㄴㄴ )

 

compare change 의 옵션은 

 

 

이렇게 창을 나눠서 바꿔준 부분을 좀 더 자세하게 비교할 수 있다.

 

마지막으로 있는 옵션인 라이브 쉐어 시작하기는 vs 코드에서 제공하는 프로그램 중 하난데, 내 코드를 원격으로 보거나 내가 다른 사람의 코드를 볼 수 있는 프로그램이다. 여기서는 필요 없으니 생략쓰

 

 

 

자 이렇게 각 옵션을 보고 내가 수정해주고 싶은대로 수정해주자. 나는 그냥 master 에 있는 코드로 수정해주기 위해서 첫번째옵션을 선택했다.

 

 

 

 

그러면 이렇게 master 에서 써줬던 코드가 자동으로 입력된다.

 

 

 

 

 

 

 

 

그렇게 해결하고 add, commit 을 해주게 되면, 컨플릭트가 잘 수정되어 넘어가고 정상적으로 작동된다!! 

 

 

짝짝 이제 merge 관련 메세지들을 자세히 정리정리

 

fast-forward 

빨리 감기라는 뜻으로 master에서 아무것도 하지않고 바로 다른 브랜치를 생성해주고 생성해준 브랜치에서 뚝딱뚝딱 만들어서 commit을 여러번 해주고 master 로 가서 merge를 실행하게 되면, master에서는 브랜치를 생성해준 것외에 별다른 것이 없고 다른 브랜치에서 여러번의 commit 이 생겼으므로 master에서는 여러번의 commit 만큼 빨리감기 해주는 상황. 

즉 master의 커밋로그에서는 여러번의 커밋이 있엇던 브랜치의 커밋로그를 가리리게 만드는 기능이다. 

 

 

recursive strtegy

이 방법은 위 방법과 달리 각각의 브랜치에서 서로 커밋을 여러번 해주었을 경우, master에서 merge를 실행 시키게 되면, 자동으로 깃은 조상 commit을 찾아 3-way merge 방법을 통해서 자식 commit을 합쳐서 새로운 커밋을 생성하게 된다.

 

 

정리하자면, merge를 실행할 때 같은 선상에 있다면 fast-forward 를, 부모 자식 관계라면recursive strtegy를 의 방법을 통해 커밋을 생성하고 merge한다고 정리할 수 있겠다. 후.. 복잡하니 이런 개념이 있다는 것만 정리정리

 

 

 

 

마지막으로 merge 옵션 1개만 정리정리...

 

--squash

이 옵션은 대상 브랜치의 모든 커밋을 하나의 커밋으로 합쳐서 merger 하는 방식이다. 작업 히스토리를 하나로 합치는 느낌정도?

이 옵션의 경우 하나의 브랜치에서 모든 작업을 하고 그 작업을 복사한 브랜치가 있다고 가정할 때, 복사한 브랜치에서 작업을 하고 커밋을 가져오지 말고 수정 내역만 가져왔으면 좋겠어! 인 경우에 쓰면 유용한 옵션이다.

 

 

---

 

깃은 쓸수록 많은 옵션들과 기능이 많아서 어렵지만....... 잘 쓰고 사용하면 그만큼 편리한 기능들이 많다고.....함미다... 예 저는 아직 어려워서 제대로 쓰지 못하지만, 프로젝트를 협업할 때 꼭 쓰는 것인만큼 공부를 더해야겠다! 후 오늘의 포스팅 끝