배경

한 사람이 계속 개발하기 위해 GitHub를 사용하기로 했습니다자습을 계속하기 위해 GitHub를 사용하여 작업 관리
그러면 GitHub 태그에 Projects가 있잖아요.나는 그것이 매우 편리한 것 같아서 한번 써 보려고 한다.

카탈로그

・ GitHub의 프로젝트는?
・ 제작 이슈부터 클로즈까지 프로젝트 협업 시도
개인적인 견해
요약

Github 프로젝트

중요한 것은 간판 기능이다.Redmine과 MS의 Planner와 같은 느낌입니다.

설정하면 issue와pullrequest와 합작하여 잘 보일 수 있습니다.

issue 제작부터 close까지 프로젝트 연합으로 해보도록 하겠습니다.

솔직히 Projects 자체가 기본 기능이기 때문에 선구자가 많다.아니면 설명을 하지 않아도 프로젝트 라벨로 보치를 하면 된다.
신중을 기하기 위해 나보다 훨씬 잘 설명한 사람의 기사를 붙여라신입사원 GitHub 프로젝트 관리 초보자
나는 먼저 To Do, In Progress, Done 판자를 만들었다.이 상태에서 issue를 하세요.다음 그림의 New issue에서 시작된 거죠?Milestone 단추에서 여러 개의 issue를 통합하여 관리할 수도 있지만, 나는 issue를 하나의 기능 단위로 나누기 때문에 사용하지 않는다.


완성된 후 오른쪽 항목에서 자신이 만든 항목을 선택하는 것을 잊지 마세요.
프로젝트에 가보도록 하겠습니다.

허허.추가됐네.뭐, New issue와 관련된 설정을 했으니까 당연하죠.
그럼 우리 in Progress로 갑시다.

어, 일하고 있나?그럼 Pullrequest를 적당히 해볼까요?

issue의 #22를 연결하여 프로젝트와 연결하십시오.그리고요?

업무가 추가되었습니다.그럼 우리 합병합시다

예, 합병 후 Done으로 이동했습니다.그리고 issue도 닫으면 끝이야.

개인 견해

한 걸음 한 걸음 증가!!!
아니오, 팀에서 임무를 관리할 때 상술한 업무 외에 누구에게 업무를 분배할 수 있습니다. PO는 프로젝트를 관리하는 데 사용하기 때문에 저는 매우 편리하다고 생각합니다.또 pull Request의 평론가가 따로 존재하면 In Progress가 될 것 같다.
하지만 한 사람이 개발한 내용을 관리하는 데는 이 절차가 필요하지 않나요...

총결산

나는 개인적으로 프로젝트가 혼자서 운용하는 규모라고 생각한다.issue를 만들어서 하나하나 처리하고pullrequest를 닫습니다.그럼 충분할 것 같아서요.
나는 눈으로 보면 관리가 잘 되는 사람이 사용할 수 있다고 생각한다.그리고 팀에서 GitHub를 활용하면 오히려 중요한 기능이니 잘 이해해야 한다.
이것은 내가 좋아하는 문제다.혼자 일하기 싫은 나.끝.