GitHub

1. GitHub

 1) 계정 생성

• https://github.com/에 접속해서 계정을 생성한다
• 계정 생성 후에는 토큰을 생성한다
• 토큰 생성 후 윈도우의 자격증명관리자 메뉴로 가서 window자격증명에 등록한다

오른쪽 상단의 메뉴에서 settings	왼쪽 메뉴에서 Developer settings

 

 2) 저장소 생성

• 메인 화면으로 돌아가서 New 버튼을 눌러 저장소를 생성한다

• owner은 본인 계정을 선택하고 Repository name에는 프로젝트 명칭을 작성한다

• Public는 전체에게 공개하는 범위이고 Private는 승인된 계정에만 공개하는 범위이다
  - Public으로 설정하여도 승인하지 않으면 변경을 할 수 없다

 2-1) 저장소 옵션 설정

• README.md 파일을 자동으로 생성한다

• Add .gitignore 설정
  - .gitignore 파일을 자동으로 생성한다
  - Java, Node.js 템플릿 중 선택하면 된다
  - Git에서 확인하지 않아야 하는 파일을 점차 추가한다

• Choose a license 설정
  - 라이센스 파일을 생성해 준다
  - 상용 소프트웨어 개발의 경우는 private 리포지토리를 사용하며, 코드를 공개하지 않기 때문에 라이센스를 보통 작성하지 않는다
  - 오픈소스 소프트웨어 개발의 경우 보통 제약이 적은 MIT 라이센스나 Apache License를 적용한다

▶ 라이선스 종류 : https://www.bloter.net/newsView/blt201410100005 

GPL·AGPL·MPL…한눈에 보는 오픈소스SW 라이선스

 

 2-2) 저장소 사용

• 저장소가 생성되면 Settings를 클릭한다

• Collaborators에 들어가서 협업자의 GitHup 아이디 또는 이메일을 입력해 준다

 

 3) 파일 올리기 

• Repository 의 Code 화면에서 해당하는 조건을 선택하여 주소를 복사한다

• git 파일을 생성했고, 파일까지 commit 한 상황이라면 두번째 조건으로 파일을 올린다
  - 3줄의 문장을 차례로 복사/붙여넣기를 하면 자동으로 실행된다
  - git remote add origin 은 로컬의 Git저장소에 원격 저장소와의 연결을 추가한다는 의미이다
  - 원격 저장소 이름에는 일반적으로 origin을 사용한다
  - git branch -M main 은 원격 저장소의 기본브랜치명을 GitHub에서 권장하는 main으로 한다는 의미이다
  - git push -u origin main 은 로컬 저장소의 커밋된 내역들을 원격 저장소로 업로드 한다는 의미이다
  - 현재 브랜치와 명시된 원격 브랜치를 기본 연결할 경우 -u 또는 --set-upstream 을 사용한다
• 저장소를 재실행하면 아래와 같이 파일이 업로드 되어 있다

• git remote 와 git remote -v 를 사용하여 원격 저장소의 내역을 자세히 확인할 수 있다

 

 4) 파일 내려받기

• Code 화면의 Code 메뉴로 들어가서 Http 주소를 복사한다
  - zip으로 내려받을 경우에는 파일에 .git 파일이 없으므로 Git이 관리를 하지 않는다

• 탐색기를 열고 저장을 하려는 폴더의 우클릭 메뉴 중 gitbash를 오픈한다
• 'git clone 원격저장소 주소' 를 사용하여 복사해 둔 Http 주소를 입력 후 파일을 내려받는다

 

 5) 파일 변경 후 업로드

• Test6 파일을 새로 생성한 후 GitHub에 업로드 한다

• GitHub의 원격 저장소를 새로고침하면 Test6가 추가된 것을 확인할 수 있다
• 이미 git push -u origin main으로 원격 브랜치가 지정되어 있기 때문에 git push 만으로도 업로드가 가능하다

 

 7) 로컬 저장소에서 작업하기

• Github 리포지토리를 생성한 후 해당 레포지토리를 로컬로 clone 받은 다음에 작업을 시작한다

git clone <git 주소>
cd <디렉터리명>

• 로컬 리포지토리에 [README.md] 파일을 추가한다
  - README.md 파일에는 다음의 정보를 포함한다
   : 프로젝트 이름
   : 프로젝트 핵심 기능 소개
   : 팀원 소개
   : Wiki로 링크

touch README.md

 

README.md 파일은 아래 정보를 꼭 포함해야 합니다.

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

# My Todo App

OOOO을 위한 웹 애플리케이션입니다.

## Features

- 편리한 UI로 OOOO를 쉽게 생성하고 삭제할 수 있습니다.
- OOOO에 기한과 카테고리를 설정할 수 있습니다.
- create-react-app으로 간편한 번들링과 배포가 가능합니다.
- Spring Boot로 쉽게 서버 배포를 할 수 있습니다.

## Contributors

- FE: OOO, OOO
- BE: OOO, OOO

## Project Wiki

프로젝트 팀 정보, 기획, 아키텍쳐에 대한 자세한 안내입니다.
http://www.ooooooooo.com/ooo?/ooo

 

 8) 협업자 간의 변경 후 파일 업/다운

• 로컬 저장소 내용과 원격 저장소의 내용이 모두 변경이 있을 경우에는 로컬에서 push를 할 경우 에러가 발생할 수 있다
• 원격 저장소의 커밋 내용을 확인하고 변경이 있다면 다음과 같은 방법으로 진행할 수 있다
  - git pull --no-rebase 는 merge 방식으로 파일을 내려받는 방식이다
  - git pull --rebase 는 rebase 방식으로 파일을 내려받는 방식이다
  - pull 진행할 경우 rebase 방식이 협업시에는 용이하다
•  git pull 을 진행한 후에 git push를 진행하면 충돌 에러가 해결된다
• git pull --force 는 강제로 이전버전의 커밋으로 돌리는 명령어이며, 협업자와 합의가 없으면 사용하지 않는다

 

2. Git Repository

• Github는 개발자의 SNS라고 불릴 정도로 다양한 종류의 오픈소스 프로젝트가 공유되어 있다

 1) 필수 파일

• README.md
  - 오픈소스 프로젝트에 들어가면, 가장 먼저 확인할 수 있는 정보가 README.md 파일이다
  - 기본적인 마크다운 사용법을 알고 있으면 간단한 소개 페이지처럼 제작할 수 있다
  - README.md 파일을 적는 양식은 따로 존재하지 않는다
  - 일반적으로 해당 오픈소스의 활용에 대한 상세한 정보가 작성되어 있다
  - Pre-Project Github 리포지토리 README.md 파일은 아래 정보를 꼭 포함해야 한다
    : 프로젝트 이름
    : 프로젝트 핵심 기능 소개
    : 팀원 소개

 

• .gitignore
  - gitignore dotfile은 git으로 관리하지 않는 파일의 모음이다
  - 주로 기록되는 파일은 다음과 같다
    : 개인이 따로 관리해야 하는 중요한 secret token
    : 다른 동료와 공유할 필요가 없는 설정 파일
    : 그 외 공유할 필요 없는 파일
  - gitignore에 기록한 파일은 git이 컨트롤 하지 않는다
  - push 할 경우에도 github 리포지토리에 push되지 않는다

 

• LICENSE
  - 해당 코드의 라이센스를 표기한다
  - 깃허브에 public하게 공개된 리포지토리도 라이센스에 따라서 사용을 할 수도 있고, 하지 못 할 수도 있다
  - 회사에서 사용하는 코드는 private으로 관리하고, 외부에 공개하지 않아 라이센스 정보를 따로 표기하지 않기도 한다
  - 만약에 회사에서 작성하는 코드가 public으로 공개된다면, LICENSE를 명확하게 표기해야 한다

 

 2) 프로젝트 관리에 활용할 수 있는 Github 기능

▶ 이슈 및 풀 리퀘스트 템플릿 정보 : https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates 

About issue and pull request templates - GitHub Docs

• Issue
  - 프로젝트에 새로운 기능을 제안하거나, 버그를 찾아 제보하는 등 프로젝트의 이슈를 의미한다
  - Pre-Project에서는 Issue를 하나의 칸반 티켓처럼 사용한다
  - 세부 설정 기능
   : Assigness : 해당 태스크를 맡은 사람을 지정할 수 있으며, assign yourself를 누르면 자신의 태스크로 만들 수 있다
   : Labels : 태스크 카드에 라벨링을 한다
   : Projects : Projects를 지정한다
   : Milestone : Milestone을 지정다.

 

• Milestone
  - 이정표의 역할 및 태스크 카드(Issue)를 그룹화하는 데 사용한다
  - Milestone에 연결된 태스크 카드(Issue)가 종료되면 Milestone마다 진행 상황이 업데이트 된다
  - Milestone 기능을 통해 연관된 이슈의 추적과 진행 상황을 파악할 수 있다
  - Pre-Project에서는 Bare Minimum, Advanced Challenge, Nightmare를 표시하기 위해 사용한다

 

• Pull Request
  - 자신이 작업한 내용을 중요 git branch에 합칠 수 있는지 확인하는 요청이다
  - Github에서는 Pull Request에서 커밋한 코드를 별도로 선택하여 해당 부분에 코멘트를 작성할 수 있다

 

• Project
  - Github 내에서 업무 관리를 해줄 수 있도록 지원하는 기능이다
  - Pre-Project에서는 이 Project 기능을 이용하여 칸반 보드를 생성하고, 칸반으로 Pre-Project의 업무 흐름을 관리한다

 

3. 칸반

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

▶ trello : https://trello.com/ 

Manage Your Team’s Projects From Anywhere | Trello

▶ monday.com : https://monday.com 

새로운 업무 방식 을 위한 플랫폼

▶ Asana : https://asana.com/ko 

온라인에서 팀의 업무, 프로젝트, 작업 관리 • Asana

▶ 작업 관리를 위한 10가지 최고의 온라인 칸반 보드 프로그램
 : https://gitmind.com/kr/kanban-board-online.html 

2022년 상위 10개 무료 칸반 보드 프로그램 및 프로젝트 관리 툴

 

 1) 칸반 보드를 통한 시각화

• 칸반 보드는 업무를 하나의 티켓으로 표현하고, 업무 단계를 하나의 열로 표현한다
• 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓이고, 업무가 잘 진행되면 가장 오른쪽으로 전달되어 쌓이는 방식이다
• 어떤 업무가 현재 어느 업무 단계에 있는지 한눈에 파악할 수 있다

 

 2) Work In Progress(WIP)로 진행중인 업무 제한 및 흐름 관리

• WIP는 현재 진행하고 있는 작업을 의미한다
• 칸반에서는 각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있다
• WIP 제한이 2이면, 두 개 이상의 카드가 해당 열에 위치할 수 없게 됩니다. 아래 예시의 경우 하나의 업무를 추가할 수 있습니다.
• 업무 흐름 관리
  - 업무가 과도하게 쌓이지 않는 원활한 업무 흐름을 위한 관리이다
  - 모든 팀원이 100%의 리소스를 사용하고 있는 상태에서 계속 새로운 업무가 쌓이게 되면, 업무가 과부하되어서 업무 효율이 나지 않게 된다
  - WIP 제한은 업무의 과부하를 조절해 주는 역할을 한다
• 진행중인 업무 제한
  - 개발 프로젝트는 타 업무와 달리 맥락 전환(context switching)이 없이 집중할 수 있어야 업무 효율이 증가한다
  - 제조업 업무는 기계 가동률을 높이거나 일부 생산을 아웃소싱하면 짧은 기간 내에 산출물을 만들 수 있다
  - 개발 업무는 지식 업무에 해당하기 때문에 야근을 하거나 인원을 많이 투입한다고 좋은 퀄리티의 산출물이 빠른 시간 안에 나오지 않는다
  - 소통이 많이 필요한 개발 프로젝트의 경우 인원수가 늘어난다고 소요 기간이 확연하게 감소하지 않는다
  - 한 번에 처리하는 업무의 양을 최소화하여 팀원이 한 번에 여러 업무를 동시에 진행해서 생기는 맥락 전환의 문제를 방지한다
  - 업무 흐름을 적당하게 유지시켜 업무가 순차적으로 처리될 수 있도록 한다

 

 3) 명확한 팀 정책 설정

• 칸반을 잘 활용하기 위해서는 정책을 설정한다
• 칸반의 열을 정의, WIP limit, 회의 일정, 의사결정 방법 등에 대한 명확한 정책을 수립해야 한다
• 정책 수립 시에는 팀원이 모두 모여서 합의를 하고, 합의한 정책은 향후 업무 진행 상황에 따라서 팀원이 모여 언제든지 조정할 수 있다
• 프로젝트 시작하기 전에 정하면 도움이 되는 정책은 아래와 같다
  - 회의 시간 및 해당 회의에서 논의할 내용을 정한다
  - 팀원 간 소통 원칙을 정한다
  - 칸반 티켓을 언제, 어떻게, 누가 추가할 것인지를 정한다
  - WIP 제한을 정한다

 

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

• 칸반을 사용하는 경우에는 일반적으로 데일리 칸반 회의와 주간 보충 회의를 진행한다
• 데일리 칸반 회의는 업무의 상태 및 흐름을 파악하고 확인한다
  - 구현하고자 하는 기능을 좀 더 빠르게 구현할 수 있는 방법을 협의한다
  - 업무가 끝난 인원이 다른 업무를 처리할 수 있는지 확인하고 진행한다
• 주간 보충 회의는 칸반 보드에 추가할 업무가 있는지를 확인하고, 다음 주에 어떤 업무를 할 것인지 정한다
  - 프로젝트 진행 상황이 매우 원활하여, 추가로 구현하기로 했던 기능을 구현할 수 있게 된 경우에는 주간 보충 회의를 통해 해당 기능 구현 티켓을 칸반 보드에 추가할 수 있다
• 추가로 격주, 혹은 월간으로 KPT 회고를 진행할 수도 있다
  - 지금까지의 진행 상황에 대해서 솔직하게 회고하고, 개선점을 찾을 수 있다

 

 5) 칸반 실천법

• 칸반의 6가지 실천법을 정리하면 아래와 같다
  1. 업무 시각화
  2. 진행 중인 업무 제
  3. 흐름 관리
  4. 명확한 프로세스 정책
  5. 피드백 루프 구현
  6. 협력적인 개선, 실험적인 발전

 

4. 레포지토리 내에 프로젝트 생성

 1) 프로젝트 생성

• 레포지토리 > Project > Add project 를 클릭한다
• 기존에 프로젝트가 있으면 선택하고, 없응면 새로 생성을 클릭한다

• Table 또는 Board 를 선택한다
  - 설정창이 뜨지 않으면 View1 옆의 아래 화살표를 클릭하면 보인다

• 오늘쪽 상단의 '...'을 클리한 후 Setting를 클릭한다

• 프로젝트의 이름과 설명을 작성하고 Save 버튼을 클릭한다

• 설정 페이지 왼쪽 탭에 Manage access 를 클릭한다
  - Base Role을 필요에 따라 선택하여 변경한다
  - 함께할 팀원이 있다면 권한을 부여하고 초대한다

 

 2) 프로젝트에 Issue 연결

• '+' 옆 칸에 '#'을 작성하여 해당 레포지토리를 찾아 선택한다
• 레포지토리 선택 후 옆 칸을 클릭하면 issue나 PR을 선택할 수 있다

• 리포지토리에 작성한 issue들이 project의 추가된 것을 확인할 수 있다
• 각 이슈들의 상태를 설정할 수 있다
  - 기본적으로 Todo , In Progress , Done 세가지 상태가 있다
• '+'를 클릭하여 Labels, PR, Reviewers, Repository, Milestone등 새로운 칼럼도 넣을 수 있다

• 그룹으로 나눠서 볼 수도 있다
  - 그룹 아이콘을 클릭한다
  - Assignees, Status, Milestone, Repository 등으로 나눌 수 있다

• Board를 선택하면 칸반보드로 볼 수 있다