코드를 작성하고 코드를 git에 업로드하는 과정에 commit을 실행할 때 해당 commit에 메시지를 남긴다. 이렇게 남긴 메시지는 github에서 내가 해당 코드를 업로드하며 남긴 메시지를 확인할 수 있다.
이 메시지에는 코드의 변경이나 어떤 것이 수정되었다 등의 코드 추가 및 변경에 대한 로그를 남겨서 알아보기 쉽게 만들어준다.
개인이 git을 가지고 혼자 알아볼 수 있는 메시지를 남기는 것은 문제될 것이 없지만, 만약 협업이나 프로젝트를 진행하며 나만 알아볼 수 있는 메시지를 남기게 되면 이것은 문제가 될 수 있다.
따라서 해당 코드를 사용하는 모든 개발자들이 알아볼 수 있도록 규칙을 통해서 commit 메시지를 남기도록 해야한다.
이 글에서는 git을 사용해 여러 사람이 같이 프로젝트를 진행할 때 commit 메시지를 남기는 방법과 git을 활용하는 방법에 대해서 알아보려고 한다.
issue
commit 메시지의 기본은 프로젝트에서 생성한 issue를 따라가는 것이다. issue는 자신이 해야할 일, 작업할 코드에 대해 간략하게 적어서 생성한다.
github의 프로젝트에 접속하면 issues라는 탭이 존재한다. 해당 탭에 접속해서 새로운 issue를 생성한다.
issue를 생성하면 다음과 같이 생성된 issue를 확인할 수 있다.
여기서 중요한 내용은 issue의 제목과 해당 issue의 넘버를 확인한다. 위의 생성한 issue의 경우에는 #1 / 헤더 링크 연결이 될 것이다.
commit 메시지
위의 내용을 활용해서 commit 메시지를 남긴다. 프로젝트에서 헤더 링크 연결과 관련된 코드만 git add를 사용해서 추가하고 git commit을 통해서 업로드되는 코드에 대한 메시지를 남긴다. 메시지를 남길 때 아래의 커밋 성격을 확인해서 해당되는 타입을 선택해서 사용한다.
feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋
예를 들어 헤더 링크 연결의 경우에는 새로운 기능을 추가하는 commit이므로 feat를 사용해서 메시지를 작성한다. commit 메시지는 헤더, 바디, 푸터로 나눠서 작성하며 헤더에는 커밋 타입과 제목, 바디에는 해당 커밋에 대한 간략한 설명, 푸터에는 issue 넘버를 작성한다. 헤더에서 작성한 내용으로 바디의 내용을 대체하는 것이 가능하다면 바디는 생략 가능하며 issue 넘버가 없다면 푸터도 생략 가능하다.
git commit -m "feat : 헤더 링크 연결
헤더의 목록에서 각각의 페이지로 이동하는 링크를 연결
issues : #1"
branch
commit 메시지를 남기는 것까지는 위의 내용들로 충분히 할 수 있을 것이라 생각한다.
다음으로 중요한 것은 branch 이름을 issue 넘버를 활용해서 생성하는 것이다. branch를 나누어 코드를 작성하면 git에 올리게 될 때 merge라는 것을 통해서 코드를 합치게 된다. 각각의 branch에서 develop을 향해서 merge를 요청하면 develop branch에서는 해당 코드들의 버그나 문제점을 확인하고 문제가 없다면 merge를 통해서 모든 코드들을 하나로 합치게 된다.
이렇게 코드를 작성하면 프로젝트를 진행하는 모든 인원이 develop branch의 코드 하나만을 다운로드 받아서 각각 수행해야할 작업만 하면 되기 때문에 협업의 효율성이 증가한다.
모든 인원이 하나의 branch에서 작업을 하게되면 각각의 코드가 충돌이 일어나 merge가 안되는 문제가 발생할 수 있어서 branch를 나누어서 작업을 한다.
대표적인 branch
1. master / main branch
가장 최상위에 위치하는 branch로 사용자에게 배포 가능한 상태만을 관리하며 배포 이력을 관리하기 위해서 사용된다. develop에서 합쳐진 코드의 시간 순서 따라서 순서대로 버전을 나누기도 한다.
2. develop
이 branch를 기반으로 개발을 진행한다.
개발자는 develop branch의 코드를 다운로드 받아서 각각 할당받은 issue 넘버에 따라서 새로운 branch를 생성하여 개발을 진행한다. 목적하는 기능들이 모두 구현되면 develop branch에서 master branch에게 merge를 요청한다.
3. 하위 branch
실제 개발자들이 코드를 작성하는 branch이다.
각각 할당받은 issue 넘버와 커밋 성격을 통해서 branch를 새로 생성하여 개발을 진행한다. 해당하는 issue의 개발이 끝나면 develop branch에게 merge를 요청하여 코드를 업로드한다.
merge
상위 branch로 merge를 요청한다는 말을 위에서 많이 썼는데 쉽게 말해서 병합한다는 의미로 코드를 하나로 합치는 과정이라고 생각하면 된다.
여러 사람이 함께 프로젝트를 진행하면 누군가는 내가 작업한 코드를 가지고 있지 않고, 나 역시도 다른 사람이 작업한 코드를 가지고 있지 않게 된다. 이 코드를 모든 사람이 가지도록 하기 위해서 일일히 카피해서 하나로 합친 다음에 다시 모든 사람에게 코드를 뿌리는 작업을 하게 된다면 매우 불편하고 귀찮은 작업일 것이다.
이를 위해서 git에서는 하위 branch들의 코드를 상위 branch에게 merge를 요청하여 하나로 합치는 작업을 진행한다.
개발자들은 develop branch에서 각각의 커밋 성격과 issue 넘버를 통해 하위 branch를 생성하여 개발을 진행한다. 작업이 모두 완료된 후에 git push를 통해서 코드를 git에 업로드할 것이다.
각각의 branch에서 작업한 코드를 git에 업로드하여 merge를 요청한다. merge 권한을 가진 사람은 각각의 코드가 충돌나지 않도록 조절하여 원래의 코드에 각각의 작업한 코드들을 합친다.
나중에 각각의 개발자들은 git pull을 통해서 그저 다운로드만 받으면 되기 때문에 더욱 쉽게 코드를 최신화 하는 것이 가능하다.
정리
위에서 설명한 모든 것은 프로젝트에서의 협업 효율성을 더 끌어올리기위해 사용하는 것들이다.
git에 업로드할 때, 모든 개발자들을 고려한 commit 메시지 작성하기.
issue 넘버, 커밋 유형에 따라 develop branch에서 새로운 branch 생성하여 작업 진행하기.
작업이 완료되면 상위 develop branch로 merge 요청해서 코드 합치기.
개발자는 항상 develop branch의 코드를 최신화해서 작업 시작하기.
위의 것들만 주의해서 작업을 한다면 프로젝트에서 협업 효율성을 높일 수 있을 것이다.
