[리액트-신입]2일차 - 팀 개발 프로세스 이해 II편( ver 22.07.01)

DEVELOP PROCESS

5. issue 처리하기

1) 개발 환경 구성 및 확인

- 사전에 권한 부여 및 ssh 계정에 등록 - 비밀번호 없이 접근가능

[참고]

SSH Key는 ssh-keygen을 통해서 생성가능 4.3 Git on the Server - Generating Your SSH Public Key https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key

 

2) branch clone 

$ git clone --single-branch - develop 또는 해당 feature  → main (X) 경고) 허가된 경우가 아니면 main branch해서 작업을 하지 않음

예) git clone -b develop --single-branch git@github.com:사용자/프로젝트명.git

[유저 지정 clone]
git clone -b develop --single-branch git@github.com:유저명/practice-git.git

[ssh] 1) main git clone git@github.com:유저명/practice-git.git 2) main이외 brach git clone -b develop --single-branch git@github.com:유저명/practice-git.git

[id/password] git clone https://github.com/유저명/practice-git.git

3) git 설정 및 확인

- git commit 과 push작업전 코드에 대한 정적 오류를 검사 작업을 하도록함
[git hooks 설정]
- git hook 스크립트 경로 : .git/hooks

git  설정 디렉토리 구조

.git/hooks/     └─ pre-commit     └─ pre-push

- 실행시 git hook skip하는 방법

--no-verify / -n 옵션을 통해서 실행

예) git commit -a -m “테스트 메시지" -n

- git hook 프로젝트 공유 -> .git은 기본적으로 gitignore대상
가. gitignore 에서 제외하기
!prepare-commit-msg.sh
!pre-push.sh 

나. 별도의 git-hooks-scripts 디렉토리에 해당 hook 스크립트를 넣고 공유

-> 개발자가 수정으로 .git/hooks에 복사해서 사용

→ 이를 자동화하는 git-hooks-setup.sh만들어서 공유

git-hooks-setup.sh : chomd +x

#!/bin/sh cp -Rf ./git-hooks-scripts/*  .git/hooks

[pre-commit :  commit 전 소스 검사 ]
- ESLint, Prettier 등을 적용한 후 commit이 되도록 함
→ husky에서 적용

[commit 메시지에 issue 번호 추가]

prepare-commit-msg.sh

#!/bin/sh # .git/hooks/prepare-commit-msg # # Automatically add branch name and branch description to every commit message except merge commit. # https://stackoverflow.com/a/18739064 # COMMIT_EDITMSG=$1 addBranchNumber() {   NAME=$(git branch | grep '*' | sed 's/* //' | sed 's/^.*\///')    DESCRIPTION=$(git config branch."$NAME".description)   echo "[$NAME] $(cat $COMMIT_EDITMSG)" > $COMMIT_EDITMSG   if [ -n "$DESCRIPTION" ]    then      echo "" >> $COMMIT_EDITMSG      echo $DESCRIPTION >> $COMMIT_EDITMSG   fi  } MERGE=$(cat $COMMIT_EDITMSG|grep -i 'merge'|wc -l) if [ $MERGE -eq 0 ] ; then   addBranchNumber fi

브랜치의 마지막 /이후의 문자만 남기기

[pre-push :  main (또는 master)에 직접 push 방지] 

pre-push.sh

#!/bin/bash # Prevents force-pushing to master/main. # chmod +x .git/hooks/pre-push BRANCH=`git rev-parse --abbrev-ref HEAD` PUSH_COMMAND=`ps -ocommand= -p $PPID` if [[ "$BRANCH" =~ ^(master|main)$ && "$PUSH_COMMAND" =~ force|delete|-f ]]; then   echo   echo "Prevented force-push to $BRANCH. This is a very dangerous command."   echo "If you really want to do this, use --no-verify to bypass this pre-push hook."   echo   exit 1 fi exit 0

[참고]

https://github.com/git/git/tree/master/templates # Install: # cd path/to/git/repo # curl -fL -o .git/hooks/pre-push https://gist.githubusercontent.com/stefansundin/d465f1e331fc5c632088/raw/pre-push

 

lint-staged - 변경된 파일에 대해서만 lint를 적용하여 lint에 소요되는 시간을 줄일 수 있음

https://www.npmjs.com/package/lint-staged https://github.com/okonet/lint-staged

[설정]   * 참고 명령 : "eslint --cache --fix"

husky - git hook의 관리를 용이하기 위해서 사용 - git hook는 기본적으로 원격에 저장되지 않음

https://www.npmjs.com/package/husky https://github.com/typicode/husky

[설정]

4) daily commit

- 업무종료전 commit으로 그날의 일과를 마무리함

git commit -a -m "2022-07-01 가장많이작업한일명+가장핵심키워드 dquote> - 작업사항 - 1 … dquote> - 작업사항  - 5 dquote> - 그외 스프린터에 할당된 과업 수행 dquote> "  ← “를 하고 엔터를 치면 메시지 입력이 종료됨 - 작업사항  최대 5개 까지 입력 ( 주로 3개이하 작성, 부득히한 경우만 5개 )

예) git commit -a -m "2022-07-01 Users 권한로직 수정 dquote> - 고객정보 수정 dquote> - 화면 로딩 속도 개선 dquote> "

5) push

- commit가 완료되면 할당된 스프린트 브랜치에 push함

 

6) PR요청 

- 단위 테스트 및 통합 테스트가 완료되면 PullRequest 요청험

- PR은 해당 스프린트 종료 전까지 완료함

 

7) review 와  merge 

- PR을 기준으로 스프린트 종료회의를 진행하고, 배포를 위해서 소스를 merge함

 

8) 시스템 테스트 후 배포

- 최종 merge된 소스를 기준으로 스테이징에 올려서 통합테스트 한후 운영서버에 반영함

Tips

[git 통계] git log --since=2022-01-01 --until=2022-01-07 | grep commit -c

[추가]

이후 팀의 개발 성숙도가 높아지면 git관련 개발 프로세스의 best practice라고 할 수 있는 gitflow의 도입을 고려해봄

https://danielkummer.github.io/git-flow-cheatsheet/index.html