- 글에 적은 내용 중 잘못된 부분은 댓글로 적어주시면 감사하겠습니다!
슬슬 Git 포스팅 내용이 지루해지는것 같아서 얼른 끝내야겠단 생각이 들었다.
Git 원격 저장소까지 빠르게 달리고 다른 글도 올려보자 😤
🔜 평화로운 병합
지금까지 브랜치 병합은 평화롭게 이루어졌다. 서로 각자의 작업파일만 손댔기 때문에, 메인 브랜치에 합치더라도 별다른 문제가 발생하지 않았다! 그런데 만약 두 개발자가 같은 파일을 수정했거나, 공동 작업인 메인 브랜치와 완전 다른 파일을 갖고 있는 개발자가 병합을 요청한다면 어떨까?
Git은 순순히 이 상황을 받아들이지 않는다. merge 명령어로 병합을 하면 대부분 진행되지만 위와 같은 상황일 경우 Git은 우리에게 경고를 한다!
- 충돌이 발생할 경우 Git은 병합을 멈추고 개발자에게 충돌(Conflict) 먼저 해결하라고 한다
🧐 병합 충돌(Conflict)
1. 충돌이 일어나면
충돌이 발생하는 경우는 한 마디로 Git이 파일의 어떤 부분이 맞는 건지 알 수 없는 상황이다.
- 다음 사진은 무엇일까?
단적인 예로 작업이 이런 착시효과 사진이라 할 때, 컴퓨터는 분별할 수 없다. 물론 사람도 둘 중 하나로 정하기 전까지 혹은 정확하게 어떤 게 맞는 것인지 확인하기 전까진 모를 것이다.
2. 충돌 발생상황
위에 사진을 다시 가져와봤다.
현재 상황은 메인 브랜치와 희동이 브랜치 병합을 진행하는 중 충돌이 발생한 것이다. 충돌이 발생한 파일인 heedong_1.txt를 열어보면 Git이 기특하게도 어떻게 차이가 나는지 보여준다.
- <<<<< Head로 된 부분은 현재 브랜치(메인)의 내용
- >>>>> heedong으로 된 부분은 충돌이 난 브랜치의 내용
3. 충돌 해결
이렇게 충돌이 났을 경우 해결하는 방법은 간단(?)하다. 직접 충돌 부분을 수정해주면 된다!
희동이가 잘못 작업했다고 가정하고 메인 브랜치가 작업한 중요내용 수정 으로 변경했다. 이후 커밋을 해주면 잘 나오는 것을 볼 수 있다.
로그가 조금 지저분해 보이지만 잘 보면 희동 브랜치와 메인 브랜치가 잘 병합된 것을 볼 수 있다
4. Cherry-Pick
브랜치를 병합하는 방법중에 체리픽(Cherry-Pick)이라는 것도 있다. 바구니 중에서 제일 좋은 체리만 골라 담는다는 의미로, 특정 커밋만 병합하는 방법이다.
아까 충돌 상황 전으로 돌아가서 만약 위와 같이 체리픽으로 메인 브랜치와 희동 브랜치의 특정 커밋을 병합하면 충돌 없이 병합할 수도 있다. 그치만 제대로 된 병합은 아니며, 희동이가 계속 개인 작업을 할 경우 잘못된 작업을 이어갈 수 있으니 상황은 봐 가면서...
🔚 마무리
병합까지 여차저차 왔다. 포스팅 텀이 자꾸 길어지는데, 이제 로컬환경에서 그만 놀고 원격 환경으로 넘어가보려고 한다. 다음에는 그 유명한 GitHub에 대한 얘기도 꺼내볼 예정이다.
& Git 강의 링크
