Unit2 - 프로젝트 시작하기

codestates/preproject

Unit2 - 프로젝트 시작하기

나아눙 2023. 4. 12. 09:46

칸반이란?

칸반은 팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법

백로그	할일	진행중	완료
로딩 속도 개선	CSS수정	Todo 컴포넌트 리팩토링

WIP는 현재 진행하고 있는 작업을 의미

각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있다.

ex ) WIP limit

업무 흐름 관리

원활한 업무흐름을 위해 WIP를 둔다.

진행중인 업무제한

맥락 전환(context switching)이 없이 집중할 수 있어야 업무 효율이 증가

*맥략전환? 한 작업에서 다른 작업으로 전환하는 과정

명확한 팀 정책 설정

합의한 정책은 향후 업무 진행 상황에 따라서 팀원들이 모여서 언제든지 다시 조정 할수 있다.

회의 시간 및 해당 회의에서 논의할 내용
팀원 간 소통 원칙
칸반 티켓을 언제, 어떻게, 누가 추가할지
WIP 제한

회의와 리뷰를 통해 함께 업무를 개선

칸반 실천법

업무 시각화
진행 중인 업무 제한
흐름 관리
명확한 프로세스 정책
피드백 루프 구현
협력적인 개선, 실험적인 발전

GitHub Issue

이슈탭에 들어가서 이슈 생성

템플릿 카드도 만들수 있다.

Settings 밑으로 가서 Features - Set up templates

GitHub Milestone

마일스톤(Milestone)은 프로젝트 관리에서 중요한 이정표 또는 단계적인 성과를 나타내는 개념입니다. 프로젝트가 특정 목표를 달성하기 위해 여러 단계로 나누어진 경우, 각 단계의 완료를 나타내는 시점을 마일스톤이라고 부른다.

이슈탭에서 마일스톤 생성

세부내역 작성

Github Project Kanban

1. Project 생성

Project 탭에서 New project 클릭

모달 창이 나타나면 Create 버튼 클릭

Settings에서 프로젝트 이름과 간단한 설명 추가

Settings에서 Manage access-Read바꿔준다.

Admin권한으로 같은 팀원 초대

ISuue 연결 - #리포지토리선택 (이슈나 PR를 선택할수 있다.)

Git branch

브랜칭(branching)은 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법

#생성
git switch -c feature
git checkout -b feature

# 기존에 있던 main 브랜치로 HEAD를 변경
git switch main
git checkout main

Merge

pull request 기능을 이용하여 변경 내역을 충분히 확인하고 난 다음에 머지하는 경우가 더 많다.

# 기능 개발이 진행되었습니다.
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# GitHub 리포지토리로 푸시합니다.
git push origin feat/todo

브랜치 삭제하기 (git branch -d)

원격 리포지토리에 pull request가 되면 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제 할수 있다.

git branch -d feat/todo

Git 설정

$ git config --global user.name "[firstname lastname]"

$ git config --global user.email “[valid-email]”

세팅 및 초기화

# 현재 디렉토리를 기준으로 Git 저장소가 생성됩니다.
$ git init

# URL을 통해 리모트 리포지토리를 로컬 리포지토리에 복제합니다.
$ git clone [url]

Stage & Commit

# 다음 커밋을 위해 현재 디렉토리에서 수정된 파일을 확인할 수 있습니다.
$ git status

# 다음 커밋을 위해 파일을 추가(스테이지)합니다. (stage)
$ git add [file]

# 추가한 파일을 언스테이징합니다. 변경 사항은 유지됩니다.
$ git reset [file]

# 스테이지되지 않은 변경 사항을 보여줍니다.
$ git diff

# 스테이지했지만 커밋하지 않은 변경 사항을 보여줍니다.
$ git diff --staged

# 스테이지된 콘텐츠를 메시지와 함께 커밋합니다. (스냅샷 생성)
$ git commit -m “[descriptive message]”

Branch & Merge

# 브랜치 목록을 보여줍니다. * 표시로 현재 작업중인 브랜치를 확인할 수 있습니다.
$ git branch

# 현재 커밋에서 새로운 브랜치를 생성합니다.
$ git branch [branch-name]

# 다른 브랜치로 전환합니다.
$ git switch [branch-name]
$ git checkout [branch-name]

# 새로은 브랜치를 생성하고 해당 브랜치로 전환합니다.
$ git switch -c [branch-name]
$ git checkout -b [branch-name]

# 현재 브랜치에 특정 브랜치의 히스토리를 병합합니다.
$ git merge [branch-name]

# 현재 브랜치의 모든 커밋 히스토리를 보여줍니다.
$ git log

공유 및 업데이트

# url을 통해 특정 리모트 리포지토리를 별칭으로 추가합니다.
$ git remote add [alias] [url]

# 별칭으로 추가한 리모트 리포지토리에 있는 모든 브랜치 및 데이터를 로컬로 가져옵니다.
$ git fetch [alias]

# 리모트 브랜치를 현재 작업중인 브랜치와 병합하여 최신 상태로 만들 수 있습니다.
$ git merge [alias]/[branch]

# 로컬 브랜치의 커밋을 리모트 브랜치로 전송합니다.
$ git push [alias] [branch]

# 리모트 리포지토리의 정보를 가져와 자동으로 로컬 브랜치에 병합합니다.
$ git pull

히스토리 수정

rebase는 커밋 히스토리를 깔끔하게 유지하면서 브랜치를 합칠 수 있는 장점이 있다.

일반적으로 개인 브랜치에서만 사용하고, 공유된 브랜치에 대해서는 머지(merge)를 사용하는 것이 좋다.

# 특정 브랜치의 분기 이후 커밋을 현재 작업중인 브랜치에 반영합니다.
$ git rebase [branch]

# 득정 커밋 전으로 돌아가며 스테이지된 변경 사항을 모두 지웁니다.
$ git reset --hard [commitish]

임시 저장

# 수정하거나 스테이지된 변경사항을 스택에 임시 저장하고 현재 작업 내역에서 지웁니다.
$ git stash

# 스택에 임시 저장된 변경사항의 목록을 보여줍니다.
$ git stash list

# 스택에 임시 저장된 변경사항을 다시 현재 작업 내역에 적용합니다.
$ git stash apply

# 스택에 임시 저장된 변경사항을 다시 현재 작업 내역에 적용하고 스택에서 삭제합니다.
$ git stash pop

# 스택에 임시 저장된 변경사항을 삭제합니다.
$ git stash drop

Coz’ Git flow

Coz’ Git flow는 중요 브랜치 두 개를 가지고 있다(main 브랜치와 dev 브랜치)

main : 사용자에게 언제든 제품으로 출시할 수 있는 브랜치(master, prod, production)

대표적인 기능이 완성

레이아웃이나 전체적인 디자인 거의 완성

웹에서 정상적으로 통신

최소 보안이 마련

브라우저에서 개발 버전에서 사용하던 secret이나 유저의 비밀번호가 노출?

유저의 기밀 정보 조회를 위해 인증 토큰, 세션이 꼭 필요?

dev(elopment) : 다음 버전 배포를 위한 "개발 중" 브랜치

프론트엔드와 백엔드의 결과를 합쳐서 확인해볼 수 있을 정도로 준비

원의 코드 리뷰를 받고 진행

feat(ure)/(작업이름): 기능 개발 , 리팩토링 , 문서 작성 등을 위한 브랜치

보통 각 개인의 로컬 리포지토리에서 만들고 작업

>refactor, fix, docs, chore 같이 세세하게 커밋 메시지나 브랜치 명에 prefix를 달기도 한다.

hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제

squash-merge 전략?

Squash-merge는 소프트웨어 개발에서 사용되는 코드 병합 전략 중 하나입니다. 일반적으로 버전 관리 시스템인 Git을 사용하는 개발자들 사이에서 널리 사용되는 전략 중 하나이다.

Squash-merge 전략은 다음과 같은 특징을 가지고 있다.

커밋을 단일 커밋으로 병합: Squash-merge는 다수의 커밋들을 하나의 커밋으로 병합하는 방식이다.
이로써 여러 커밋들이 하나의 커밋으로 합쳐지므로 브랜치의 히스토리가 단순해지고, 불필요한 커밋들이 줄어들어 더 깔끔한 히스토리를 유지할 수 있다.
커밋 메시지를 재작성: Squash-merge는 여러 커밋을 하나로 병합하기 때문에 커밋 메시지도 재작성될 수 있다. 병합하는 커밋들의 메시지를 통합하거나, 새로운 커밋 메시지를 작성하여 병합된 커밋의 내용을 명확하게 설명할 수 있다.
커밋 히스토리를 깔끔하게 유지: Squash-merge를 사용하면 브랜치의 히스토리가 깔끔하게 유지된다.
병합된 커밋들이 하나의 커밋으로 합쳐지므로, 불필요한 커밋들이 줄어들고, 히스토리가 깔끔하게 정리되어 다른 개발자들이 코드를 이해하기 쉬어진다.
작업 브랜치의 히스토리를 보존: Squash-merge는 작업 브랜치의 히스토리를 보존하는 특징이 있다. 작업 브랜치의 커밋 히스토리를 유지하면서, 통합 브랜치의 히스토리를 깔끔하게 정리할 수 있다.

Squash-merge는 간단하고 깔끔한 히스토리를 유지하고자 할 때 유용하게 사용되는 코드 병합 전략 중 하나이다.

이슈는 프로젝트의 작업 항목을 개별적으로 관리하고 논의하는 데 사용되며,

마일스톤은 프로젝트의 전체 진척도와 작업 계획을 파악하는 데 사용

프레임 워크 설치

npx create-react-app {원하는 디렉터리 경로}

npm install @reduxjs/toolkit react-redux

npm install --save styled-components

ESlint, Prettier

npm install -D eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-prettier eslint-config-prettier

// .eslintrc.json
{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:import/recommended",
    "plugin:jsx-a11y/recommended",
    "plugin:prettier/recommended"
  ],
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "rules": {
    "react/react-in-jsx-scope": 0,
    "react/jsx-uses-react": 0
  }
}

// .prettierrc.json
{
  "singleQuote": true
}

ESLint, Prettier VSCode Extention을 설치

설치 완료 후 설정으로 이동 ,editor.codeActionsOnSave 설정

onSave 검색 -> Edit in settings.json클릭

저장을 하면 코드의 오류나 잘못된 코드 스타일링을 찾아 자동으로 수정한다.