한 개발자가 하루에서 수도 없이 커밋(Commit)을 하고 있다면 소스코드관리시스템을 백업서버로 쓰고 있을 가능성이 높습니다.
사실 이러한 경우를 매우 자주 봤습니다.
혹시 코딩을 하다가 점심 먹으러 간다고 한번 커밋하고 중간 중간에 수시로 커밋을 하고 있으면 이건 좋은 방법은 아닙니다.
혹시 이런 방법으로 소스코드관리시스템(SVN, CVS, VSS, ClearCase 등)을 사용하고 계신지 확인해보십시오. 본인이 아니라도 이렇게 백업용도로 사용하고 있는 동료나 후배가 없는지 확인해보십시오.
커밋을 하면 소스코드의 Revision이 바뀌게 되는데, 각각의 Revision은 의미를 가지게 됩니다.
그 의미가 "점심 먹으러 나가면서 임시로 저장" 이렇게 되면 곤란합니다.
각 Revision의 정보는 우리회사 개발의 역사로서 영원히 남게 되는데 그런 쓰레기 정보를 남기면 안되죠.
누군가는 각 Revision에서 바뀐 내용을 알기 위해서 Diff를 해볼 것이고, 이를 이용해서 Merge도 할 수 있고, 원 소스코드 작성자에게 내용을 물으러 올 수도 있습니다.
그래서 커밋(Commit)은 아무 때나 아무렇게나 하면 안됩니다. 각 회사마다 소스코드관리시스템을 사용하는 규칙이 필요하고, 이를 지켜야 합니다.
소스코드를 수정하기 위해서는 항상 버그ID(Issue ID)가 필요하며 그에 따른 수정 내용은 한번에 커밋을 하는 것이 바람직합니다. 그리고 커밋을 할 때는 회사의 규칙에 맞는 형식으로 Message를 남겨주어야 합니다. 이때 버그ID와 수정 내용 및 Peer Review(Desk check 정책을 사용할 경우)를 한 사람은 꼭 기록하는 것이 좋습니다.
이렇게 쌓인 소스코드관리시스템의 History와 마구잡이로 규칙없이 사용한 History는 나중에 그 가치와 활용도가 확연히 차이가 나며 개발 생산성에 많은 영향을 주게 됩니다.
사소해 보이지만 쌓이면 정말 큰 차이가 나는 중요한 개발 규칙 중 하나입니다.
이미지출처 : Microsoft Office Online
