내일배움캠프 11일차 TIL
오늘의 학습 키워드
- 깃 커밋 컨벤션
- 깃 플로 컨벤
오늘은 Git Commit Convension과 Git Flow Convension에 대해서 정리 겸 포스팅해볼까 합니다.
깃 커밋 컨벤션은 왜 하는 것일까?
그 이유는, Git을 사용하는 이유는 당연히 많은 개발자와 협업을 하기 위해서입니다.
그리고 수많은 개발자들이 Git 내에서 여러 Branch로 나눠서 작업을 합니다.
그렇기에 수많은 정보들이 Commit이 됩니다.
이 때 어떤 내용이 Commit이 됐는지 같이 협업하는 사람들이 알아야 하며,
나중에 문제가 발생했을 때 Undo나 Redo 등을 하기 위해서,
알아보기 쉽게 정보를 적을 필요가 있습니다.
그래서 서로의 약속으로 깃 커밋 컨벤션을 각 팀별, 각 회사별로 정합니다.
깃 커밋 컨벤션 기본 구조
깃 커밋 컨벤션의 기본 구조는 아래와 같습니다.
Type : Subject
Body
Footer
타입은 일종의 태그와 비슷합니다.
Subject는 Commit 내용의 간단한 요약, 즉 제목입니다.
Type : Subject 예시
Type
feat : 새로운 기능
fix : 버그 수정
docs : 문서 수정
refactoring : 리펙토링
test : 테스트
comment : 주석 추가 및 변경
remove : 파일, 폴더 삭제
rename : 파일, 폴더명 수정
Subject
Add : 추가
Remove : 삭제
Update : 변경
Implement : 구현
위의 방식이 정답은 아니지만 위와 같이 컨벤션을 적은 이용은
처음에 해보는 협업이기에 너무 많은 부분을 정하고 가기 보다는
많이 사용할 것 같은 내용을 위주로 컨벤션을 정의했습니다.
Body
Body에서는 해당 Commit에 대한 구체적인 내용을 적습니다.
어떤 내용을 추가하고 어떤 내용을 변경했는지,
각각의 행동에 대한 이유 또한 적어줍니다.
단, 한 줄의 길이를 최소한으로 작성해줍니다.
만약 제목에서 이미 충분히 알 수 있을 정도로 작성했다면,
Body는 생략해도 무방합니다.
Footer
Footer는 기본적으로 생략을 해도 문제 없습니다.
꼬릿말이라는 뜻으로 해결한 이슈의 커밋 ID나 해결하기 위해 참고한 커밋 ID 등
일종의 Commit계의 주석 같은 것입니다.
ex) Resolves # 161
See Also : #1245
Git Flow Convension
Master/Main 브랜치 : 최종 완성된 제품을 위한 Branch
Develop 브랜치 : 다음 출시 버전을 개발하기 위한 Branch
Feature 브랜치 : 기능을 개발하는 브랜치
그 외에 아직 2개의 Branch가 더 존재했던걸로 아는데,
아직 공부가 부족하기에 해당 내용은 추후에 포스팅 하겠습니다.
저 같은 경우에는 시작부터 너무 많은 것들을 하려고 하지 않고
3가지 Branch 종류를 가지고 Git Flow 전략을 구성했습니다.
Master에는 대규모 업데이트가 있을 때 Master에 모든 Branch를 병합
Dev에서는 각 중요 큰 틀을 분류로 나누기
Feature는 각 Dev에서의 기능별로 나누기
지금은 위와 같은 형태로 Branch를 생성했습니다.
하지만, 해당 포스트를 작성하면서 생각이 바뀐거 같습니다.
다음 방식은 아래와 같이 할 예정입니다.
1. Main/Master는 Dev가 완성이 되면 Dev의 내용을 Merge합니다.
2. Dev는 큰틀로 기능을 나누지 않고 다음 버전을 예정으로 잡고 하나만 생성합니다.
3. Feature는 진행중인 Dev에서 기능별로 생성합니다.
단, Feature명 뒤에는 반드시 /(이름)을 붙여줍니다.
그래야 해당 Feature의 기능을 누가 담당하는지 직관적으로 알 수 있기 때문입니다.
오늘의 회고
팀 활동을 본격적으로 시작한지 벌써 2일째입니다.
첫 날에는 갑자기 팀 활동을 하면서, 조정해야할 것, 구성해야할 것, 공부해야할 것이 너무 많아서
정신 없이 흘렀던 것 같습니다.
2일 째인 오늘은 스크럼과 ,깃 플로우, 코드 구성 등 매우 팀으로써의 결단력과 협동성이 증가한 것 같습니다.
아직 부족한 것은 많지만, 이번 팀이 만들어 낼 결과물이 매우 기대가 됩니다.
