[TIL] 24_0110 git switch -c / github - issue, pull request 사용하기

두번째 팀프로젝트를 시작하며,

프로젝트를 기획하며 제일 먼저 코드와 깃 컨벤션을 정했어.

모두가 쓰는 개인 코드와 깃 커밋을 쓰는 방법이 달라서 각자 어떻게 쓰는 지 알아보고 공통으로 쓰이는 위주로 선정해서 정했어.

파일 이름과 변수 이름을 카멜 케이스로 하고 클래스 이름은 대쉬(-)를 이용했어.

 

git

세션에서 git의 심화된 부분을 배우는 중 새로 알게 된 게 있어. 

 

-git switch -c : 브랜치를 만들며 이동.

 

사용법

$ git switch 이동할 브랜치 이름
$ git switch -c 내 브랜치 이름

 

첫번째, git switch는 브랜치를 이동할 때 쓰고,

두번째, git switch -c는 내 브랜치를 생성(create)하는 동시에 그 브랜치로 이동할 수 있어.

 

주로브랜치 이동할 땐 git checkout을 자주 썼는데 checkout 기능이 광범위하다면 switch는 딱 관련 기능만 쓸 수 있어서 기능면에 있어서 안 했갈리고 명령어도 직관적이어서 더 좋은 것 같아. 이번 기회에 계속 써보면서 익숙해져야겠어. 

 

 

git convention

-git commit 커밋 메세지와 github의 issue 이용

 

commit

커밋 메세지 쓰는 형식이 팀원별로 달라서 통일하기로 했고 동시에 커밋을 통해 github의 issue와도 연동해서 써보기로 했어. 써본 분의 경험으로 설명을 듣고 다같이 써보기로 했어. issue사용은 정말 유익한 것 같아.

issue를 써보긴 했지만 이렇게 커밋을 이용한 issue사용은 처음인 것 같아.

 

브랜치 명은 [타입]_기능이름/이슈번호 이렇게 정했고 이슈 이름은 [타입] - 설명 이렇게 했어.

예를 들어, 타입은 깃 컨벤션의 Feat을 쓰고 기능 구현에 붙인다고 하면 [Feat] - 설명 이렇게 하는거야.

브랜치 명은 [Feat]_reviewRead/#7 이런 식으로

 

 

 

-issue

- 팀원들과 각자의 고민과 구현 정도를 공유해서 코멘트를 받고 해결할 수 있어.

 

 

 

-pull request

- 파일을 최종 브랜치에 올릴 때 메인 브랜치에 합치기 전에 합치기 위해 점검해달라며 요청하는 거야. 

- 허락되면 본인 또는 점검해주는 사람이 Merge pull request를 눌러줘서 최종 브랜치와 합치게 되는 거야.

- 그리고 이슈를 올린 것과 연관지어서 pull request도 할 수 있어! (아래 사진 참고)

 

 

느낀점

- issue 잘 쓰고 있다고 생각했는데 이번에 타이틀과 커밋으로 이슈등록해보면서 issue를 더 잘 활용해봐야겠단 생각이 들었어.

- github project, wiki도 쓰면서 todo와 와이어프레임 등 관리도 조금씩 해보려고.

- 팀원과 코드리뷰도 하는 동시에 코드 점검도 할 수 있어서 좋은 것 같아. 코멘트로 해결이 안 되면 live share또는 스피커 리뷰까지도!