1. Git 컨벤션
By. IT 임익환

2. 목차
1. 컨벤션 작성 계기
2. Fork
3. Merge
4. Commit 양식
5. Branch
6. 관련 자료

3. Git 컨벤션 문서 작성 계기
목차
1. 기존 Commit 메시지 구조
2. Conflict 문제

4. 기존 commit 메시지 구조
 문제점
 가독성이 떨어짐 (본인만 알아봄)
 유지보수 어려움
 잘못된 메시지 옵션(feat, fix)
 commit 메시지를 상세하게 작성하여
로그 관리를 해야 유지보수성을 높일 수 있다

5. Conflict 자주 발생 문제
문제점
 원본 저장소로 바로 Push를 한다.
 동시에 작업 시 Conflict 문제가 자주 발생한다.
해결방안
 원본 저장소를 Fork 하여 작업한다.
 나만의 Branch가 생기는 것과 비슷하다.
(방법은 뒤에)

6. Fork
목차
1. Fork하는 방법
2. 주의 사항
3. Fork 장점

7. 1. Fork하는 방법
기존에는 원본 저장소에서 바로
Clone하여 작업했었다.

8. 2. Fork하는 방법
1. 깃랩 원본 저장소에서 Fork를 누른다.

9. 3. Fork하는 방법
동일한 이름의 프로젝트가 나의 소유로 생긴다.

10. 4. Fork하는 방법
나의 저장소로 들어가서 똑같이 Clone을 한다.

11. 5. Fork하는 방법
1. 방금 Clone 받은 폴더 경로를 Git bash를 통해 들어간다
2. Git remote -v를 입력한다.
3. Origin이 나타날 것이다.

12. 6. Fork하는 방법
1. 여기에 git remote add upstream “원본 저장소주소”
명령어를 입력한다.
2. 원본 저장소 주소는 내가 Fork를 눌렀던 저장소에서
Clone 버튼을 누르면 볼 수 있다.

13. 7. Fork하는 방법
1. 다시 git remote -v를 입력해서 origin과 upstream
두 개가 나타나면 성공

14. 주의 사항
Fork를 하여 나의 저장소에서 작업할 때에는
버전 최신화가 중요하다.
나의 저장소가 checkout된 상태에서
1. git pull upstream/브랜치명
2. git push origin/main
방금 추가한 upstream에서 pull을 받고
Origin에 그 내용을 push하는 과정이다.
이것을 통해 원본 저장소와 내 저장소 내용이 같아진다.
명령어를 작업전이나, 수시로 하여 버전 최신화를
해주어야 conflict를 최소화할 수 있다.

15. Fork의 장점
- Conflict를 최소한으로 방지할 수 있음
- 추 후에 코드리뷰를 도입할 수 있음.

16. 원본으로 Merge하는 방법
목차
1. 원본 저장소로 Merge하는 방법

17. Merge 방법
나의 저장소에서
Merge requests 진입

18. Merge 방법
New merge request 클릭

19. Merge 방법
Merge를 원하는 branch를 선택하고 continue

20. Merge 방법
제목과 내용은 상세하게 commit들과 관련되게 작성한다.
해당 내용으로 Merge기록이 남기 때문

21. Merge 방법
불필요한 commit이 많다면 Squash를 사용한다.
여러 개의 commit을 하나로 묶는 기능이다.
* 상세한 Merge request 메시지 작성을 통해
무엇을 squash 했는지 설명 필수

22. Commit 메시지 양식
목차
1. 메시지 구조
2. 제목 작성 방법
3. 내용 작성 방법
4. 푸터 작성 방법

23. 메시지 구조
 제목(title), 본문(body), 꼬리말(footer)로 구분한다.
예시

24. 제목 작성 방법
태그(목적): 제목
1. 50자 이내로 작성
2. 마지막에 .을 넣지 않는다.
3. 개조식 구문으로 작성
예시)
Feat: 회원 get함수 추가
일반적인 태그 종류

25. 제목 작성 방법
 간소화된 제목 타입
제목 태그 이름 설명
Feat 새로운 기능을 추가할 경우
Fix 버그를 고친 경우, 기존 기능 수정, 삭제
Style
코드 스타일 변경, 세미콜론 추가, 줄 바꿈, Eslint,
Prettier를 통한 수정사항 (CSS아님)
Design CSS관련
Refactor 프로덕션 코드 리팩토링(기능 변경X)
Test 테스트 코드 관련
Chore 패키지 설치, 변경이나 config, env 등 설정 관련
Docs 문서(README.md, ppt등), 주석 수정
File 파일 이름 수정, 삭제, 이동
Build 도커 등 배포 관련 내용

26. 제목 작성 방법
타입 뒤에 “:”를 붙여 제목과 구별
타입 뒤에 정보 제공 목적을 괄호() 안에 적을 수 있음(optional)
ex) Fix(database): Commit title
chore(package): 패키지 업데이트
Feat(explode): explode 관련 00기능 추가

27. 내용 작성 방법
제목 아래에 한 줄 띄우고 작성하는 메시지는 본문이 됨
1. 한 줄 당 72자 내로 작성
2. 최대한 상세하게 작성
3. 무엇을 왜 변경했는지 설명
예시)
작성한 본문은 깃랩 히스토리에서
… 버튼을 누르면 볼 수 있음.

28. 내용 작성 방법
SourceTree에서 작성 예시

29. 꼬리말 작성 방법
맨 마지막 줄에 작성함
1. 선택사항임
2. 여러 개의 번호를 적을 땐 , 로 구별
연동된 redmine 일감 번호를 넣으면 redmine에서
커밋 내역 확인이 가능하다.

30. 꼬리말 작성 방법
양식 정리
제목 태그 이름 설명
Ref 관련된 일감
Related to 해결중인 결함
Resolves 결함 해결했을 때

31. Branch 전략
목차
1. 보편적인 Branch 형식
2. 현재 적합한 전략

32. 보편적인 Branch 형식
많이 알려진 브랜치 사용 패턴이다.
Feature을 만들어서 작업 > dev에 병합 > main 에서 배포한다

33. 보편적인 Branch 형식
하지만 현재 우리는 구성원이 적고 (Server)
보통 한 사람이 하나의 기능을 담당하기 때문에
Feature 브랜치 사용 대신 Fork 기능으로 충분하다고 생각.(개인의견)
Main, Dev 두 개의 브랜치만 두고
Dev에 작업한 내용을 Main에서 배포하는 방식 사용.
Fork해도 기존 feature 브랜치 전략은 사용 가능하다.(자유)

34. 관련 자료
목차

35. 관련 자료
협업을 위한 git 컨벤션
https://overcome-the-limits.tistory.com/6
Commit Message / PR 잘 쓰는 법
https://velog.io/@ye-ji/Git-PR-%EC%9E%98-
%EC%93%B0%EB%8A%94-%EB%B0%A9%EB%B2%95

36. 끝
목차