프로젝트 GitHub
GitHub Repository
Repository에 반드시 필요한 파일
- README.md
- 오픈 소스 프로젝트에서 가장 먼저 확인 할 수 있는 정보
- 기본적인 마크다운 방법으로 작성 가능
- 양식은 따로 없지만 보통 해당 오픈 소스를 어떻게 활용할 수 있는지에 대한 상세한 정보를 작성함
- .gitignore
- gitignore dotfile. git으로 관리하지 않는 파일 모음
- 공유할 필요 없는 파일을 기록하면 git이 이를 파악하지 않고 push할때도 Repo에 Push 되지 않음
- 예) 개인이 따로 관리해야하는 중요한 secret token, 다른 동료와 공유할 필요없는 설정 파일 등
- LICENSE
- 해당 코드의 라이센스
- 대부분 회사에서 사용하는 코드는 private로 관리하고 외부에 공개하지 않기때문에 라이센스를 따로 표기하지 않을 수도 있음
- public으로 공개될 경우 꼭 LICENSE를 명확하게 표기해야 함
프로젝트 관리에 활용할 수 있는 GitHub 기능
- Issue
- 프로젝트에 새로운 기능 제안, 버그 제보 등 프로젝트의 이슈를 의미
- 이 프로젝트에서는 하나의 칸반 티켓처럼 사용함
- Milestone
- 이정표 역할을 하고 태스크 카드(Issue)를 그룹화 하는데 사용
- 태스크 카드가 종료되면 Milestone마다 진행 상황이 업데이트 됨
- 연관된 이슈의 추적과 진행 상황을 한눈에 파악할 수 있음
- 프로젝트에서는 난이도를 표시하기 위해 사용함
- Pull Request
- 내가 작업한 내용을 중요 Git branch에 합칠 수 있는 지 확인하는 요청
- PR에서 커밋한 코드를 따로 선택해 해당 부분에 코멘트를 달 수도 있음
- 현업에서도 PR을 보고 코멘트를 남기면서 코드리뷰를 진행함 ⇒ 익숙해질 필요 있음!
- Project
- 업무 관리를 해줄 수 있는 기능
- 프로젝트에서는 칸반 보드 생성에 사용함
GitHub Project Kanban
칸반이란?
팀과 조직이 작업을 시각화 하고 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법
특징
- 칸반 보드를 통한 시각화
- 업무 = 티켓 1개, 업무 단계 = 열 1개
- 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓임
- 진행이 잘 되면 가장 오른쪽으로 전달되어 쌓임
- ⇒ 어떤 업무가 현재 어느 업무 단계에 있는지 한눈에 파악 가능
- Work In Progress(WIP)로 진행중인 업무 제한 및 흐름 관리
- 업무 제한
- WIP = 현재 진행하고 있는 작업
- 칸반에서는 각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있음
- ⇒ 제한 이상의 업무가 해당 열에 위치할 수 없음
- 업무 흐름 관리
- WIP를 두는 이유는 업무가 과도하게 쌓이지 않는 원활한 흐름을 위해서임
- 업무가 과도하게 쌓인 상태에서 새로운 업무가 쌓일 경우 과부하되고 효율이 나지 않음
- 특히 개발 프로젝트는 맥락 전환(context switching) 없이 집중할 수 있어야 업무 효율이 증가함
- ⇒ 한번에 처리하는 업무의 양을 최소화 하여 팀원이 한번에 여러 업무를 동시에 진행해서 생기는 맥락전환의 문제 방지, 업무 흐름을 적당히 유지시켜 차근차근 처리되게 함
- 업무 제한
- 팀 정책 설정
- 칸반을 잘 활용하기 위해서는 명확한 정책이 수립되어야 함
- 정책 수립시 팀원이 모두 모여서 합의를 해야하고, 향후 업무 진행 상황에 따라 언제든 다시 조정할 수 있음
- 프로젝트 시작 전 정하면 좋을 정책
- 회의 시간 및 해당 회의에서 논의할 내용
- 팀원간 소통 원칙
- 칸반 티켓을 언제 어떻게 누가 추가할지
- WIP 제한
- 프로젝트 시작 전 정하면 좋을 정책
- 회의와 리뷰를 통한 업무 개선
- 보통 칸반을 사용하는 경우 데일리 칸반 회의와 주간 보충 회의를 진행함
- 데일리 칸반 회의
- 업무의 상태 및 흐름을 관찰하고 추적
- 구현하려는 기능을 어떻게하면 더 빠르게 구현할지, 업무가 끝난 인원이 다른 업무를 당겨올 수 있는지 등을 정할 수 있음
- 주간 보충 회의
- 칸반 보드에 추가할만한 업무가 있는지 확인
- 다음주에는 어떤 업무를 할 것인지 정하기
- 격주나 월간 등으로 회고를 진행할 수도 있음
- 데일리 칸반 회의
- 보통 칸반을 사용하는 경우 데일리 칸반 회의와 주간 보충 회의를 진행함
칸반 실천 방법 요약
- 업무 시각화
- 진행중인 업무 제한
- 흐름 관리
- 명확한 프로세스 정책
- 피드백 루프 구현
- 협력적인 개선, 실험적인 발전
칸반 원칙
칸반 실천법은 칸반 원칙을 잘 지키기 위해 만들어짐. 지금 하고 있는 작업이 원칙에 맞는지 고민해볼것
- 하던 업무를 칸반 보드에 올려두기
- 점진적인 변화 추구
- 칸반은 현재 하고 있는 일이나 업무를 잘 수행하기 위한 하나의 수단.
- 칸반을 위해서 갑작스럽게 업무 방식을 극적으로 변화시키지 말아야 함
- 당장 내가 할 일부터 하나씩 올려두는것으로 시작할것
- 직위에 관계 없이 리더십 발휘
- 팀장만 관리하는 것이 아니라 팀원도 WIP 제한을 늘리거나 줄이는 것을 제한 할 수 있고, 새로운 업무 티켓을 발행하거나 기존 업무 티켓의 진행을 도울 수 있음
프로젝트 Git flow
Git branch
브랜칭(Branching) : 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 함. 메인 개발 코드를 건드리지 않고 작업할 수 있는 버전 관리 기법.
main 브랜치에서 feature 브랜치 생성 ⇒ main 브랜치는 유지되고 feature 브랜치에서 자유롭게 코드 추가 및 삭제가능.
git switch : 브랜치 생성 / 변경
switch : 새로운 브랜치로 git이 바라보는곳. Head를 변경하는 작업.
브랜치 생성시에는 -c (create)를 붙여줌. 기존 브랜치로 옮길때는 붙이지 않아도 됨
명령어
// 새로운 feature 브랜치 생성하고 switch함
git switch -c feature
// checkout 도 사용 가능
git checkout -b feature
// 기존 main 브랜치로 switch함
git switch main
git checkout main
git merge : 브랜치 합치기
기능 개발이 끝났을때 메인 브랜치와 합치기 위해 이용
// 개발 하면서 커밋
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
// 머지를 위해 main으로 브랜치 전환
git switch main
// 전환한 브랜치(main)으로 feat/todo 브랜치를 병합
git merge feat/todo
실제 개발시에는 브랜치를 로컬에서 합치기 보다는 Pull Request 기능을 이용하여 변경 내역을 충분히 확인 한 다음 머지한다.
⇒ 로컬에서 머지하지 말고 해당 브랜치를 push하여 pull request를 요청하는 것을 권장.
// 개발 진행
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
// GitHub 리포지토리로 푸시
git push origin feat/todo
// GitHub에서 Pull Request
git branch -d : 브랜치 삭제하기
머지된 브랜치는 이미 dev 브랜치에 기록이 완벽하게 남아있기 때문에 굳이 남겨둘 이유가 없음으로 삭제를 권장.
원격 리포지토리에서 PR이 성공적으로 마무리 되면 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제할 수 있다.
git은 브랜치가 합쳐지지 않으면 삭제하지 못하도록 설정되어있음.
// 일반적인 브랜치 삭제
git branch -d feat/todo
// 다 만들지 못한 기능의 기록을 삭제할때
git branch -D feat/todo
머지되지 않은 브랜치 삭제는 버전 기록 시스템의 사용 목적과는 맞지 않음.
⇒ 잘못 만든 기능이지만 해당 기능으로 돌아가고싶을 수도 있음으로 돌아갈 여지를 남겨두는 것이 좋다. 이런경우는 팀 / 회사 정책을 따를것.
'study > TIL' 카테고리의 다른 글
타입스크립트 기본 복습 정리 (0) | 2023.06.16 |
---|---|
4월 19일 TIL (0) | 2023.04.20 |
4월 1일 TIL (0) | 2023.04.02 |
Optimization (0) | 2023.03.30 |
TDD 방법론 (0) | 2023.03.29 |