Git/Github(2)

HyunSooBae·2022년 10월 6일

MegabyteSchool 개발자취업부트캠프 국비지원교육 내일배움카드 메가바이트스쿨 패스트캠퍼스

프론트엔드 공부

목록 보기

4/13

Commit

작성한 코드를 원격 저장소에 저장할 때, 커밋을 날린다고 표현한다. Git/Github(1)에서 작성한 대로 로컬에서 작업한 내용을 stage에 보내고, 거기서 commit을 하면 원격 저장소에 저장되는 것인데 개발 과정 중 기점을 만들어 수많은 버전을 만드는 것이라고 봐도 될 것 같다.

작성법

원활한 협업을 위해 지켜야 할 부분 중 하나. 커밋 컨벤션 사이트를 참고하자. 유다시티의 커밋 메세지 작성 가이드도 보편적으로 따르는 가이드인듯 하다. 대략적인 내용은 이렇다.

제목, 본문(선택), 꼬리말(선택) 으로 구성된다.

제목은 접두사로 타입(Type)라벨을 맨 앞에 붙인다. 접두사의 종류는 여섯가지가 있다. (제목의 처음은 동사 원형으로 시작하고 첫 글자는 대문자로 작성, 과거시제가 아닌 명령어로 작성한다)

feat: 새로운 기능을 추가할 경우
fix: 버그를 고친 경우
docs: 문서 수정한 경우
style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
refactor: 프로덕션 코드 리팩터링
test: 테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 없음)
chore: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)

본문은 커밋의 상세 내용을 작성한다. 한 줄에 72자 이내로 작성하고, 문단을 나누거나 불렛을 사용하여 내용을 구분한다.
꼬리말에는 이슈 트래커ID를 추가해도 좋다.

커밋 메세지 예시

feat: Update index.html with a new line

예시를 봐도 고민되는 커밋 메세지... 구글에 커밋 작성법 등의 키워드로 검색하면 참고할 내용이 많이 나온다!

주의할 점

commit은 동작 가능한 최소단위로 자주 할 것. (한꺼번에 모든 파일과 코드를 커밋하지 말자!)
해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
모두가 이해할 수 있는 log를 작성할 것.
Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를
따라 쓸 것.
제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가설명 할 것.
제목과 내용은 한 줄 띄워 분리할 것.
내용은 이 commit의 구성과 의도를 충실히 작성할 것.

Branch

각각의 개발자들이 독립적으로 어떤 작업을 진행하기 위해 만드는, 일종의 임시 복제 저장소 같은 것. 브랜치 간에는 서로 영향을 주고받지 않기 때문에, 개발자가 각자의 독립적인 브랜치 안에서 마음대로 소스 코드를 주무를 수 있다. 이때 분리된 브랜치에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수가 있다.

Branch model - Git-flow

브랜치 모델로 Git-flow, Github-flow, Gitlab-flow 등이 있다. 이중 표준처럼 가장 많이 사용되는 것은 Git-flow 모델이다.
Git-flow는 5개의 브랜치를 사용하는데 각각 master, develop, feature, release, hotfix 가 그것이다.

master : 제품을 배포하는 브랜치
develop : 개발자들이 각자 작업한 내용을 합치는 브랜치
feature : 단위 기능을 개발하는 브랜치
release : 배포를 위해 master 브랜치로 보내기 전 품질검사를 위한 브랜치
hotfix : 배포 이후 긴급한 버그가 생겼을 때 사용하는 브랜치

Git-flow strategy