프로젝트 협업을 위한 깃 브랜치, 충돌에 대한 개념

프로젝트를 진행하기 위해 협업을 위해 소스트리를 사용하게 되었다.

필요한 깃 개념을 정리해보자!

 

브랜치의 목록에 마스터라는 기본 브랜치가 생성된다.(마스터도 하나의 브랜치로 보는 개념!)

고객사마다 브랜치를 만든다고 가정하면,,

 

브랜치를 생성하면 위와 같이 나열되고, 왼쪽 사이드바에 표시된 브랜치가 현재 위치하고 있는 브랜치를 나타내주는 것이다.

 

파일이 변경되면 위와 같이 커밋하기 않은 변경사항이라고 뜬다. 

커밋하면 히스토리에 추가된다.

마스터 브랜치에서 커밋했기 때문에 위와 같이 표시된다.

이제 브랜치를 옮겨서 파일을 열어보면 파일의 내용이 변경된다. 마치 저장소 전체를 복제한 디렉토리를 보는것과 같은 효과인 것이다.

 

이제 애플 브랜치에서 apple.text를 만들고, work.txt에서 수정을 하면 다음과 같이 브랜치가 분기한다.

master브랜치로 들어가면 apple.text는 사라진다.

히스토리를 분석해보면 ,

apple브랜치의 부모는 커밋3, master work4의 부모는 마찬가지로 커밋 3이다. 

apple과 master는 공통의 작업(work 4)과 서로 다른 작업(apple.txt)을 가지고 있다는 것도 알 수 있는 것이다.

 

 

 

병합할때

누구를 누구에게 병합할것인가를 명확히 해야 한다.

마스터로 병합한다 : 마스터 브랜치로 가서 opentutorials를 현재 브랜치로 병합하기 하면

마스터브랜치에도 opentutorials에서 만든 파일이 복제된다.

즉, 맨 위의 히스토리는 병합된 파일이고, 이것의 부모는 master work 5와 opentutorials work 5이다.

 

서로다른 브랜치가 서로 같은 파일을 수정했다

-> 1. 서로 다른 부분을 수정했다. 같은 파일내에서 각각 다른 브랜치에서 다른내용을 수정하고 머지해도 합쳐진다!

-> 2. 서로 같은 부분을 수정했다. -> 충돌발생!

 

<<<<head는체크아웃한 브랜치에 현재 가리키고 있는 버전

즉 그 밑 , master는 opentutorials브랜치에서는 똑같은 부분에 opentutorials라고 작성했다고 알려주는 것.

=======는 구분자

파일을 직접 기호들 제거하고 수정하거나, 소스트리에서 내것으로 해결, 또는 their로 해결 을 선택한다.

파일을 직접 수정한 경우, 수정하고 나서 소스트리에서 해결된 것으로 표시를 누른다.

그리고 커밋누르면 알아서 충돌이 있었음을 알리는 커밋메세지가 작성된다.

 

 

 

충돌을 좀더 이해해보자 3 way merge

 

파일에 a b c d라는 내용이 있다. (문단4개, 또는 함수 4개)

버전관리를 위해 a에서 브랜치를 만든다. 이름은 here, there

각각 다른부분에 수정한 곳도 있고, 같은 곳을 수정한 곳도 있다.

이 상황에서 두 브랜치를 합칠 때 어떤 것이 자동으로 , 어떤것이 수동으로 병합되어야 하는가.

합칠 곳의 내용이 같다면 충돌이 안나는거고, 다르면 난다는 것이다.

 

 

두개의 브랜치를 비교해서 병합하는 방법은 2way merge이고

3 way merge는 더 많은 부분을 자동화해준다.

공통의 조상을 base라고 한다(base는 브랜치의 이름이 아니다.)

조상과도 비교해서 둘다 수정된 경우는 병합할 수 없어 충돌이 일어나는것이고,

조상과 같다면 수정이 안된것이고 다른경우는 수정된 것이기 때문에 수정된 것을 반영하면 되는 것이다.

 

 

 

외부도구 머지 툴 - p4merge이용해보기