일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- PYTHON
- DRF
- django rest framework
- django widget
- react
- django ORM
- web
- 파이썬
- Baekjoon
- Git
- form
- es6
- 알고리즘 풀이
- Algorithm
- java
- HTML
- API
- 알고리즘 문제
- Django
- 백준
- js
- 파이썬 알고리즘
- CSS
- AWS
- c++
- 알고리즘
- 장고
- javascript
- MAC
- 알고리즘 연습
- Today
- Total
수학과의 좌충우돌 프로그래밍
07.git merge, 그 종류와 충돌 해결 본문
안녕하세요 강민성입니다.
이번 포스팅에서는 나뉘어진 branch 들을 병합하고, 이에 따라 생기는 문제를 해결해보도록 하겠습니다.
저번 포스팅을 보시고 본다면
금방 따라오실 수 있을 겁니다.
branch 병합
우선 실습은 저번 포스팅에서 하던 디렉토리에서 이어서 하도록 하겠습니다.
현재 디렉토리의 상황을 보면,
master에서 1,2 commit 을 한 후 exp branch 에서 3을, master에서 4를 한 상황입니다.
따라서 현재 exp 와 master는 다른 내용이고 이번 시간이 이 둘을 합쳐보도록 하겠습니다.
이렇게 합치는 것을 merge 라고 하는데
merge는 어디서 어디로 하는지가 중요합니다.
지금은 master에서 exp 의 내용을 가져와 합치겠습니다.
그러기 위해서는 우선 master로 이동을 해야합니다.
그 후
git merge {가져올 branch 이름}
다음 명령어로 내용을 합칠 수 있습니다.
그 결과, 두 개가 하나로 이어져 새로운 commit 이 생겼습니다.
exp 는 아직도 commit 3에 머물러 있습니다.
이번에는 master의 내용을 exp로 merge 해보도록 하겠습니다.
exp로 이동해 merge를 해주면 당연하게도 exp와 master가 같아지며 가장 최신 버젼에 있게 됩니다.
방금 두 번의 merge를 하였는데 사실 두 merge는 방식이 다릅니다.
이 부분에 있어서는 조금 뒤에서 설명하도록 하겠습니다.
이제 merge가 완료 되었으니 exp branch 가 필요없어졌습니다.
exp를 지우기 위해서는 다른 branch 로 이동 후 지워줘야 합니다.
이 때 만약 merge를 하지않은 branch 를 지우려고 하면 merge 전이라고 error 메세지가 나오는데,
d를 D로 바꿔
git branch -D {삭제할 branch 이름}
를 통해 강제로 지울 수 있습니다.
이제 branch 는 master 하나 남았습니다.
merge 도 다 같은 merge가 아니다?
merge를 하게 되면 아래 이미지 3번째 줄처럼 fast-forward 라는 설명이 나옵니다.
이것이 merge의 방식을 나타내는 설명입니다.
git 공식 홈페이지, document 에 있는 예시를 참고해서 이해해보겠습니다.
다음과 같은 상황을 가정해보겠습니다.
master branch에서 3개의 commit 을 한 후,
iss53 branch 를 만들고 4번째 commit,
hotfix branch를 만들고 5번째 commit 을 했습니다.
첫 번째 상황은 hotfix의 내용을 master에 merge 하는 상황입니다.
이 상황이 바로 fast-forward 입니다.
hotfix branch 의 commit이 현재 master가 가르키는 commit 기반이기 때문에
master는 굳이 새로운 commit을 생성할 필요없이 hotfix가 가르키는 버젼으로 이동만하면 됩니다.
새로운 commit 이 없다는 점이 중요합니다.
이번 상황은 위 상황에 이어서 iss53 branch 의 내용을 master에 merge 하려 합니다.
이런 경우를 3-way merge 방식이라고 하며 fast-forward 대신
merge made by the 'recursive' strategy
다음과 같은 message를 출력합니다.
최종적으로 두 branch 의 내용을 아우르는 새로운 버젼이 생기고 master가 그 곳으로 이동합니다.
merge 시 문제가 생긴다면?
git 은 알아서 merge를 잘해주지만 그렇지 못한 경우도 있습니다.
그 상황을 알아보도록 하겠습니다.
아까 지웠던 exp branch를 새로 만들고
master branch에서 master.txt 파일에 내용은 master로, 메세지는 5로 commit 해줍니다.
다음으로는 exp branch로 넘어가서 exp.txt 에 내용은 exp, 메세지는 6으로 commit 해줍니다.
현재 git graph는 다음과 같습니다.
서로 다른 branch 에서 commit 을 했기에 다시 분기되었음을 볼 수 있습니다.
위에서 했던 것 처럼 master로 넘어와 exp 의 내용을 merge 해주면
문제없이 합쳐지고 새로운 commit이 생깁니다.
이렇게 서로 다른 파일을 merge할 경우에는 문제없이 merge가 진행됩니다.
이번에는 같은 양 쪽 branch에 같은 파일을 만들어보겠습니다.
exp branch에서 common.txt 파일을 만들고 내용은, common in exp
메세지는 7로 commit 해주었습니다.
master에서 exp를 merge 하면
master에도 common.txt 이 생긴걸 확인할 수 있습니다.
master의 common.txt의 내용을 아래와 같이 수정 후, commit 메세지 8
( 여러 상황을 보기 위해서 commit 도 많고 헷갈리실 수 있습니다.
천천히 따라와주세요 )
exp의 common.txt 의 내용을 아래와 같이 수정 후 commit 9
다시 master로 이동 후 exp 를 merge하고 내용을 확인하면
양 쪽 파일에서 수정한 내용이 함께 있습니다.
즉, 같은 파일이더라도 수정한 위치가 다르면 문제없이 merge가 됩니다.
이제 master와 exp에 있는 common.txt를 각각 다음과 같이 수정 후,
commit 10, commit 11로 새로운 버젼을 만들었습니다.
그 후 master에 exp를 merge 하게 되면
다음과 같이 충돌이 일어났다는 메세지가 출력됩니다.
git status로 상태를 확인해보면
common.txt 가 양 쪽에서 수정되어서 merge 할 수 없다고 합니다.
common.txt 의 내용을 확인해보겠습니다.
적은 적도 없는 새로운 문구들이 많이 등장하는데 git이 사용자에게 충돌을 알려주는 표시입니다.
먼저 ========= 를 기준으로 위아래로 나뉜다고 생각합시다.
<<<<<<<<<<< HEAD 아래 부분은 HEAD가 가르키는 branch,
즉 우리가 checkout 하고 있는 branch의 내용을 의미합니다.
>>>>>>>>>>> exp 윗 부분은 exp branch의 내용을 의미합니다.
저 부분들을 사용자가 직접 수정을 해주었습니다.
별 의미는 없지만 다음과 같이 바꿔주고 다시 commit 을 진행하면,
conflict 가 있었다고 이를 알려줍니다.
정상적으로 commit 을 하게 되면,
무사히 파일의 내용이 바뀐 것을 확인할 수 있습니다.
마무리
실습을 진행할 때는 파일도 하나고 굉장히 쉬운 예제로 하고 있어
충돌이 별 거 아닌 것 처럼 보일 수도 있지만 실제로 많은 파일을 관리하는데 있어서는
어려운 부분 중 하나 입니다.
그리고 최대한 간단하게 쉽게 설명을 하고자 했지만 commit 수도 많아지고
내용도 횡설수설이 되는 것 같습니다.
많은 상황을 다루고자 하는 것이니 이해하고 따라와 주시면 감사하겠습니다.
'git' 카테고리의 다른 글
[git] 한글 깨짐 현상 해결 (0) | 2020.04.07 |
---|---|
08.git stash, 책갈피처럼 사용해보자 (0) | 2019.02.09 |
06. git branch 생성과 정보확인하기 (0) | 2019.02.07 |
05. git의 원리(2) commit, status의 원리 (0) | 2019.02.06 |
04. git의 원리(1) gistory와 add의 원리 (0) | 2019.02.05 |