소스코드 Conflict

소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.

하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

2008/11/21 - [기반시스템/소스코드관리] - Diff and Merge in SCM(Software Configuration Management)
2009/02/25 - [기반시스템/소스코드관리] - Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.