[Day 2] 01_프로젝트 전 과정, 지식_22.12.18

**프로젝트 과정
>1. Github repo에 필요한 파일
-README.md
: Markdown 양식의 파일
: 프로젝트 이름, 프로젝트 핵심 기능 소개, 팀원 소개와 같은 해당 Github repo의 안내서와 같은 역할을 함.
-.gitignore
: 말 그대로 git이 관리하지 않도록 무시하는 파일의 목록을 설정하는 파일
: 해당 파일에 설정된 파일 혹은 디렉토리 경로는 local repo에서 git으로 관리되지 않으며, push를 해도 github repo에 push되지 않는다.
-LICENSE
: 해당 코드의 라이센스를 표기
: 해당 코드를 public으로 공개할 경우에도 저작권은 존재하기 때문에 이를 라이센스로 표기하는 것임.
: 오픈 소스 사용 및 배포 시, 지켜야할 규칙, 이용 방법, 조건 범위 같은 느낌
: 개인, 상용화 목적, 혹은 회사의 코드와 같이 private으로 사용하는 경우는 라이센스 표기를 하지 않아도 무관
: 오픈 소스나 혹은 다른 목적이라도 public으로 배포하는 경우에는 표기하는 것이 좋음.

//라이센스 따로 정리
https://wooono.tistory.com/379

>2. 프로젝트 관리에 활용하는 github 기능
-Issue
: 앞으로 할 일, 기능 제안, 예상치 못한 문제 조우 및 해결 등과 같은 작업(task)을 의미
: 하나의 작업(task)를 팀에서 어떻게 정의할 지 사전에 상의하는 것이 좋음.
-Milestone
: Issue를 그룹화하여 해당 Issue 그룹의 진척도를 시각화 시켜줌.
: 따로 생성하지 않아도 Project의 기능으로 알아서 해결도 되어보임.
-Pull Request
: 개인 branch에서 작업한 내용을 팀 branch에 합칠 때, 합칠 수 있는지 확인하는 요청
: conflict를 줄일 수 있는 방법이다.
: 또한 해당 pull request를 보내면서 개인 branch에서 작업한 내용을 설명하는 글을 쓸 수 있고, 팀원에게 해당 pull request에 대한 리뷰를 받을 수 있다.
-Project
: Issue, Milestone을 담는 테이블이라고 생각하면 좋다.
: 한 눈에 프로젝트가 어떻게 진행되고 있는지 시각화하여 파악할 수 있다.

//기본 project와 project(classic)
: project(classic)을 개선한 것이 project이고, 현재는 default가 project인 것 같다.
: 내 기준에서는 project를 잘 활용하려면 issue와 milestone을 따로 관리하고 그것을 project로 가져와서 한 눈에 보게 만드는 것 같다.
: project(classic)은 project 내에서 가볍게 issue를 만들 수 있고 done에 위치시키면서 project 전체의 milestone을 확인할 수 있는 것 같다.
: 개인적으로는 project(classic)이 가볍고 편해보인다. 그렇지만 project에 대한 내 이해가 부족해서 그런걸지도 모름. 좀 더 공부가 필요함