기본 프로젝트 세팅과 git

프로젝트 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

머지되지 않은 브랜치 삭제는 버전 기록 시스템의 사용 목적과는 맞지 않음.

⇒ 잘못 만든 기능이지만 해당 기능으로 돌아가고싶을 수도 있음으로 돌아갈 여지를 남겨두는 것이 좋다. 이런경우는 팀 / 회사 정책을 따를것.