GitHub(깃허브) Issue(이슈)와 milestones(마일스톤)

1. GitHub 기초

 

 

1) 용어

push: 로컬 리포지토리 -> 원격 리포지토리로 보내기

pull: 원격 리포지토리 -> 로컬 리포지토리로 가져오기

pull request: 제안 사항 보내는거

issue: 역할 할당(assign) + 프로젝트에서 해결해야하는 문제 -> 버그 신고, 기능 추가 등 개선 제안

ex. 이슈 등록, 이슈 맡을게요 이런 식

branch: 각자 맡은 작업

merge: branch 작업을 commit 하는 것

staging 혹은 add: 원하는 것만 commit

commit: 현재 프로젝트 상태를 찰칵 사진 찍듯이 저장 하는 것

checkout: 작업할 브랜치로 바꾸는 것

 

 

.git폴더 안보임!!!ㅠㅠㅠㅠ 단축키 cmd+shift+. 하면 됨(소스트리에 뜨면 된거니까 ㄱㅊㄱㅊ)

 

소스트리에서 오른쪽 마우스에서 삭제: 북마크 제거는 소스트리에서만 사라짐, 휴지통으로도 이동은 프로젝트 통째로 사라짐

git에 설정이나..등등 오류 있을때 .git만 삭제하고 다시하면 됨

 

회사마다 commit형식이 있음 회사에서 일할때 그 규칙 따라가면 됨

 

터미널로 사용해야 모든 기능을 사용할 수 있는데 UI를 선호하면 소스트리 사용

 

 

 

1. 버전관리를 한다는 건 어떤 의미일까? 아주 중요함 에러가 난 상황에서는 돌이킬 수 있고, 문제점을 빨리 찾을 수 있음 
2. 작업내역 단위인 commit에는 어떤 정보가 포함되어 있어야 잘 버전 관리를 할 수 있을까? 파일 한번에 commit하는건 나중에 찾아볼 때 힘들 듯 따로따로 수정내용 직관적으로 commit내용이 들어가야 관리가 용이 할 듯
3. 지금까지 우리가 실습은 어떤 순서로 했었지? txt파일 작성->commit->수정->commit

 

 

원격 repository

로컬 repository

 

tracking: 로컬repo를 원격repo에 연결하는 것 (branch tracking 브랜치 단위로 추적하는 것)

clone: 원격repo에서 내 컴퓨터로 가져오기

 

 

1. 원격repo와 로컬 repo를 연결해서 내용을 반영하고 싶을 땐 어떤 방법을 써야할까? 원격repo와 로컬repo 연결 방법은 로컬repo에서 설정-원격-추가-이름:origin url: 넣기(?) 또는 깃에서 원격 repo를 먼저 만들고 메인  내 컴퓨터에 폴더 만들고 소스코드에서 새로만들기 URL 복제 원격repo 코드에서 https의 url복사한거 붙여넣음
2. 원격repo와 로컬repo는 왜 따로 있을까? 원격은 사람들과 공유 또는 클라우드 저장?목적으로 있는거고 로컬은 혼자서 컴퓨터에 가지고 있는거…
3. push와 pull의 개념을 원격 repo와 로컬 repo를 포함해 그림으로 그려보세요. 생각완..

 

merge(병합) 방법

해당 브랜치로 체크아웃(더블클릭) -> 상단에 병합 클릭

아래 옵션 3가지 체크(순서대로 123)

 

소스트리에서 태그

origin/main: 원격repo의 저장 되어있는 것

main n개 앞: origin/main태그가 있는(원격repo)보다 n개의 작업 더 했다는것

push하면 태그가 원격repo랑 로컬 repo랑 같아짐

 

 

merge 충돌(conflict): 같은 부분 수정 했을 때 파일과 파일 또는 파일 안에 소스 코드일 수 있음

head부분이 main 브랜치 내용/ 아래 다른 브랜치 내용

수정하면 됨(내용은 안에 있는거 안에서 수정하고 추가하지말기! 나중에 추적 어려움)

충돌이 복잡해지면 브랜치 삭제하기

 

 

2. 이슈(issue)

버그 수정, 새로 추가될 기능, 개선해야하는 기능 등등 모든 활동 내역에 대해서 issue를 등록하고 그 이슈 기반으로 작업을 진행

 

1) issue 생성: new issue

issue내용: 이슈 내용 요약 설명 / 이슈 내용 상세 설명 / 체크리스트

assigneer: 이슈의 작업자=이슈 작업의 담당자

labels: 해당 작업의 분류

keyword : 의미
bug : 예기치 않은 문제 또는 의도하지 않은 동작(버그)을 나타냅니다.
documentation :문서를 개선하거나 추가 할 필요가 있음을 나타냅니다.
duplicate : 해당issue 또는 PR이 기존에 있음을 나타냅니다.
enhancement : 새로운 기능 요청을 나타냅니다.
good first issue : 처음 기여해볼 사람에게 좋은 문제를 나타냅니다.
help wanted : 관리자가 문제 또는 PR 요청에 대한 도움을 원함을 나타냅니다.
invalid : 이슈 또는 PR 요청이 더 이상 관련이 없음을 나타냅니다.
question : 이슈 또는 풀 요청에 추가 정보가 필요함을 나타냅니다.
wontfix : 문제 나 PR 요청에서 작업이 계속되지 않음을 나타냅니다.

 

 

2) 해당 issue 해결 후 commit

// issue 관련 commit
git commit -m "[#{이슈번호}]{메시지내용}"

// 예시
git commit -m "[#34]issue check"

3) issue 해결 완료 시 close issue

 

 

3. milestones(마일스톤)

프로젝트 성공을 위해 반드시 거쳐야 하는 중요한 지점을 뜻 합니다.

 

👉🏻 프로젝트 진행 시 시간흐름에 따라 특정시점의 포인트를 지정하여 의미를 주는 것

👉🏻 프로젝트 진행 시 특별한 이슈가되는 시점이 있다면 마일스톤으로 지정하여 사용

 

 

프로젝트의 주 단위 목표 혹은 주요 기능 단위에 대한 여러 개의 Milestone들을 만들 수 있습니다.

 

👉🏻 개발 목적에 따라 이슈를 만들고 이슈의 묶음로 활용하기

1) 개발 목적에 따라 Milestone으로 만들고 관련 이슈 생성

2) 이슈의 묶음인 마일스톤 이용하기

- 특정 마일스톤 시점까지 개발되었으면 하는 feature 나 fix 되었으면 하는 bug 들이 이슈로 등록되어 있다면 마일스톤 지정을 통해서 해당이슈들을 마일스톤 별로 묶어서 볼수 있음

-  Milestone에 등록한 이슈들을 추적하여 진행 상황을 Progress bar로 확인 할 수 있음

 

 👉🏻 Due Date를 설정하고 해당 기간 동안 수행할 Issue들을 등록해 진행 상황을 확인

-  close-beta, open-beta , release 등과 같은 특정 목표를 설정하여 이용

- v1.0, v2.0 등과 같이 목표하는 버전을  목표로 설정하여 이용