8/22 (월) [Pre-Project] 프로젝트 시작하기

 

 

 

 

🍉 GitHub 레포지토리에 꼭 필요한 파일

 

 

🥝 README.md

포함할 정보들

• 프로젝트 이름
• 팀원 소개
• 핵심 기능 소개

 

 

🥝 .gitignore

git으로 관리하지 않는 파일 모음

개인이 관리해야하는 secret token, 공유할 필요없는 설정 파일 등을 추가

 

 

🥝 LICENSE

라이센스 표기

오픈소스 소프트웨어 개발은 보통 제약이 적은 MIT 라이센스나 Apache License 적용

다양한 라이센스가 있어서 필요한 걸로 적용

 

 

 

🍉 프로젝트 관리에 활용할 수 있는 GitHub 기능들

 

1. Issue

새로운 기능을 제안하거나 버그를 제보하는 등 프로젝트 이슈를 올리는 곳

Pre-Project에서 하나의 칸반 티켓으로 사용하면 된다.

 

 

2. Milestone

이정표 역할

task 카드(Issue)를 그룹화하는데 사용

연결된 태스크 카드가 종료되면 Milestone마다 진행 상황이 업데이트

 

 

3. Pull Request

작업한 내용을 branch에 합칠 수 있는지 확인하는 요청

커밋한 코드를 따로 선택하여 해당 부분에 코멘트(코드 리뷰)를 달 수 있음

머지의 규칙을 정할 수도 있음

 

 

4. Project

업무 관리를 해줄 수 있게 돕는 새로운 기능

칸반 보드를 생성하고 칸반으로 Pre-Project의 업무 흐름을 관리

 

 

☛ 칸반 보드란?

업무를 효율적으로 관리하기 위한 시각적 프로젝트 관리의 한 형태

칸반이란? 팀이 수행해야 하는 업무와 각 팀원이 맡을 수 있는 작업량 간에 균형을 맞추는 수단

칸(看, Kan, 신호), 반(板, Ban, 판)

칸반보드에서 업무를 열로 구성된 프로젝트 보드에 표시한다.

각 열은 업무 단계를 나타냄

기본적인 틀 : 할 일, 진행 중, 완료

개별작업은 보드에서 비주얼 카드로 표시

 

 

 

 

✅ Work In Progress(WIP)로 흐름 관리

 

진행 중인 업무의 개수를 제한하여 과도하게 업무가 쌓이지 않아 원활한 업무 흐름을 만들어 낼 수 있다.

팀원이 100%의 리소스를 사용하는 상태에서 새로운 업무가 쌓이게 되면 업무 과부하로 효율이 안나올 수 있다.

단기간에 많은 아웃풋을 내려고 하면 금방 지쳐서 번아웃이 올 수 있으므로 적당하게 분배하자.

업무 개수를 적절하게 정해서 맥락 전환(context switching) 없이 현재 하고 있는 프로세스에 집중할 수 있게 하여 업무 효율이 증가한다.

 

 

 

✅ 명확한 팀 정책 설정

 

칸반을 잘 활용하기 위해서는 정책을 설정해야 한다.

언제든 팀원이 모여서 다시 조정 가능하다.

 

 

✅ 회의와 리뷰를 통한 업무 개선

 

데일리 칸반 회의

주간 보충 회의

월간 또는 주간으로 KPT 회고를 진행하는 것도 좋음

 

 

 

🍉 GitHub Milestone

 

GitHub 마일스톤 튜토리얼

 

여러가지 이슈들을 그룹화해서 진척도를 한눈에 볼 수 있다.

 

예) Bare Minimum Requirement, Advanced Challenge

 

 

 

🍉 변경사항 PR 하기

 

🥝 Pull Request 시 체크하면 좋은 것들

• title이 올바른 이슈 타입인가
• 특정 이슈를 해결할 때, PR의 제목에 issue 넘버가 적혀있는가 (ex. fix #12)
• 커밋 제목이 가이드라인을 따랐는가
• 변경사항의 테스트가 추가되었는가
• 문서들이 추가되거나 업데이트 되었는가
• breaking change를 소개하지 않거나 breaking change에 대한 설명이 있다. (? 무슨말인지 잘 이해가 안간다)

👆🏻 출처 nhn tuieditor

위와 같은 자료들을 참고해서 Pull Request 에 대한 가이드라인이나 체크리스트를 작성해두는 것이 좋다.

 

 

새로운 branch 를 만들어서(feat: xxx) main  브랜치의 변경없이 새로운 기능을 구현한 후 마치면 main(또는 dev) 브랜치에 합친다.

merge 된 branch는 기본적으로 삭제하지만 나중에 다시 볼 일이 있다면 삭제하지 않아도 된다.

 

 

🥝 브랜치 생성하기 (create 옵션 -c)

 

git switch -c feature/sign-up
git checkout -c feature/sign-up

 

 

🥝 기존 브랜치로 옮기기

 

git switch main
git checkout main

 

 

🥝 main 브랜치에 병합하기

 

git merge feature/sign-up

 

 

🥝 merge된 브랜치 삭제하기(delete 옵션 -d)

 

git branch -d feature/sign-up

➡️ branch가 합쳐지지 않으면 삭제하지 못하도록 설정되어 있음.

merge 하지 않고 삭제하고 싶으면 -D 옵션을 사용하면 됨

 

 

 

🍉 Git 헷갈리는 명령어

 

git reset [file]

-> 추가한 파일을 언스테이징, 변경사항은 유지됨

 

git diff

-> 스테이지되지 않은 변경 사항을 보여줌

 

git diff --staged

-> 스테이지했지만 커밋하지 않은 변경사항을 보여줌

 

git branch

-> 현재 브랜치 목록을 보여줌(*표시가 현재 작업중인 브랜치)

 

git branch [branch-name]

-> 현재 커밋에서 새로운 브랜치를 생성한다.

 

git branch -c [branch-name]
git checkout -b [branch-name]

-> 새로운 브랜치를 생성하고 작업을 해당 브랜치로 전환한다.

 

git merge [branch-name]

-> 현재 브랜치에 특정 브랜치를 병합한다.

 

git log

-> 현재 브랜치의 모든 커밋 히스토리를 보여줌

 

git log B..A

-> 브랜치B에 없는 브랜치A의 모든 커밋 히스토리를 보여줌

 

git log --follow [file]

-> 해당 파일의 변경 사항이 담긴 모든 커밋을 표시(파일 이름 변경도 표시)

 

git diff B...A

-> 브랜치A에는 있지만 브랜치B에 없는 것의 변경내용(diff)을 표시한다.

 

git remote add [alias] [url]

-> url을 통해 특정 원격 저장소를 별칭으로 추가한다.

 

git fetch [alias]

-> 별칭으로 추가한 원격 저장소에 있는 모든 브랜치 및 데이터를 로컬로 가져옴

 

git merge [alias]/[branch]

-> 리모트 브랜치를 현재 작업중인 브랜치와 병합하여 최신상태로 만듬

 

git push [alias] [branch]

-> 로컬 브랜치의 커밋을 리모트 브랜치에 전송함

 

git pull

-> 원격 저장소의 정보를 가져와 자동으로 로컬 브랜치에 병합 (pull = fetch + merge 이라서 pull을 주로 사용)

 

git rebase [branch]

-> 특정 브랜치의 분기 이후 커밋을 현재 작업중인 브랜치에 병합 (merge와 비슷하지만 다르다.)

 

git reset --hard [commitish]

-> 특정 커밋 전으로 돌아가며 스테이지된 변경 사항을 모두 지움

 

git stash

-> 수정하거나 스테이지 된 변경사항을 스택에 임시 저장하고 현재 작업 내역에서 지움

 

git stash list

-> 스택에 임시 저장된 변경사항의 목록을 보여줌

 

git stash apply

-> 스택에 임시 저장된 변경사항을 현재 작업 내역에 적용함

 

git stash pop

-> 스택에 임시 저장된 변경사항을 현재 작업 내역에 적용하고 스택에서 삭제함

 

git stash drop

-> 스택에 임시 저장된 변경사항을 삭제함

 

 

🍉 Git flow

 

유명하고 많이 쓰이는 branch 전략이다.

 

🥝 Coz’s Git flow

-> Git flow를 단순화

 

🥝 Coz’s Git flow 브랜치 전략

 

• main : 사용자에게 언제든 배포할 수 있는 브랜치
• dev : 다음 버전 배포를 위한 "개발 중" 브랜치
• feat/작업이름 : 기능 개발, 리팩토링, 문서 작성등을 위한 브랜치

 

branch에 대한 최소한의 기준을 팀원과 상의할 필요가 있음!

 

어떤 때 dev -> main 으로 merge 할지?

예시) 대표적 기능 완성, 기획한 레이아웃과 전체적 디자인 얼추 완성, 클라이언트-서버-데이터베이스가 공개된 웹에서 정상적으로 통신, 최소한 보안 마련

 

 

⭐️ 실제 프로젝트 때는 브랜치를 로컬에서 합치기 보다 pull request 해서 같이 코드 리뷰를 충분히 하거나 확인을 하고 머지하는 것이 바람직하다. (로컬에서 머지 ❌, 브랜치 PR 요청 ✅)

 

✔️ branch는 기능별로 만들고 기능별로 담당자를 선정한다.

 

 

개발환경 구성(Back-End)

1. 통합 개발 환경 선택 (IDE)

IntelliJ

 

2. JDK 선택

AdoptOpenJDK가 많이 사용됨 (표준은 아님)

버전 11 지정

 

3. Framework 선택

Spring-boot 사용

버전은? 2.7.1 버전으로 지정

 

4. build 방식 선택

Gradle 방식 사용

-> XML 방식으로 작성하는 Maven보다는 Groovy 방식으로 작성하는 Gradle이 작성 및 문제 해결 시 용이

 

5. 형상관리(Software Configuration Management) 방법 결정

버전관리 및 개발 협업을 위한 형상관리

GIthub