[ GitHub 사용 설명서 ] Chapter-2. 프로젝트 보기

종류 : 대학교 도서관 소장 도서

제목 : GitHub 사용 설명서

저자 : Peter Bell & Brent Beer

번역 : Ann Lee

소개 : bnitech.tistory.com/8

단지 공부의 목적으로 해당 도서 및 자료를 정리해둔 것입니다.

GitHub 사용 설명서

프로젝트 보기

예제

• 부트스트랩 (bootstrap)
• https://github.com/twbs/bootstrap

프로젝트 페이지 소개

< GitHub의 프로젝트 페이지 홈페이지 >

• 왼쪽 위 
• 프로젝트 이름이 "bootstrap"이고 "twbs"라는 사용자(예제의 경우 단체)가 소유 하고 있다는 것

• http:/github.com/twbs 
• GitHub에서 이 단체가 관리하는 프로젝트 목록을 모두 볼 수 있다.

• 단체명의 왼쪽
• 누구나 볼 수 있는 공개 리포지토리
• 임을 알려주는 아이콘이 표시되어 있다. 
• 이와 달리 잠김 열쇠 아이콘이 있으면 프로젝트가 비공개이며 협력자로 확실히 추가된 사람들만 볼 수 있음을 의미한다.

• 프로젝트명의 오른쪽
• 7,000명이 새로운 변화가 생길 때마다 알림을 받기 위해 리포지토리를 주시하고 있다.
• 112,574명이 즐겨찾는 프로젝트를 나타내는 별점을 주고있다. 
• 52,206명이 리포지토리를 fork 하였다.

• 페이지 아래로 더 내려가면
• 프로젝트에 대한 간략한 설명이 나와 있다.

• 그 아래에
• 총 16,458번의 변경이 있었음 (commits),
• 현재 28가지의 다른 hitiory가 개발되고 있음 (branches),
• 추천 소프트웨어로 41개 버전이 있음 (releases) 
• 866명이 코드의 일부분을 작성하였음 (contributors)

• 그림의 중앙
• 현재 v4-dev 브랜치 (branch) 를 보고있다.
• 부트스트랩 (bootstrap) 루트 폴더에 있다

• 그림의 아래쪽
• 프로젝트의 루트(최상위 레벨)폴더에 있는 폴더들(디렉토리)과 파일들을 볼 수 있다.

README.md 파일 보기

< 프로젝트의 README.md 파일의 콘텐츠 (상위 일부분) >

• 프로젝트의 루트에 README.md라는 파일이 있으면 그 파일의 콘텐츠가 프로젝트 홈페이지의 폴더와 파일 목록 바로 아래에 표시된다.

• 이 파일은 프로젝트에 대한 소개와 협력자들에게 유용한 정보(소프트웨어를 어떻게 설치하는지, 자동화된 테스트를 어떻게 실행하는지, 코드를 어떻게 사용하는지, 프로젝트에 어떻게 기여할 수 있는지 등)를 제공한다.

• 요즘 들어 README 파일은 배지(badges)도 자주 포함하는데, 배지는 자동화된 테스트 슈트(test suite)같이 프로젝트의 현 상태를 알려주기 위해 사용되는 이미지이다.

Commit History 보기

< 프로젝트의 최근 commit 목록 >

• commit history는 어떤 특정 브랜치에서 작업이 완료되었을 때 가장 최근 작업이 무엇인지 알아보는 좋은 방법이다.

• GitHub의 부트스트랩 페이지로 이동해 "16,458 commits" 링크를 클릭한다. (여러분이 클릭했을 때는 commit수가 달라져 있을 것이다.).

• 가장 최근의 작업 목록 위쪽에 오는 순서로 commit 목록이 표시 된다.

< 프로젝트의 최근 commit >

• 각 commit을 클릭하면 변경이 된 이유를 설명하는 commit 메시지가 표시 된다. 

• 그 아래로 commit 일부분으로 추가되거나 삭제 또는 수정된 각각의 파일을 볼 수 있다.

• 삭제된 콘텐츠는 빨간색으로, 추가된 콘텐츠는 녹색으로 표시된다.

Pull Requests 보기

< 프로젝트의 공개 pull request >

• Pull Request는 현재 진행 중인 작업이 무엇인지 알 수 있게 해준다.

• 홈페이지로 돌아가 오른쪽 위의 "Pull Request" 리으를 클릭하면 공개된 pull request 목록이 표시된다.

• 이는 사람들이 현재 작업하고 있는 기능이나 수정사항을 나타낸다.

< 최근의 pull request >

• pull request 중 하나를 클릭하면 그 pull request를 설명하는 짧은 제목을 볼 수 있다.

• 변경안을 포함하는 하나 또는 그 이상의 commit이 있으며, 그 변경안에 대해 논의하고 있는 사람들이 달아놓은 댓글이 많을 수도 있다.

• pull request를 살펴 보면 사람들이 현재 무슨 작업을 하고 있으며, 버그 수정을 하든 기능 개발을 하든 각각의 변경 사항에 대해 어떤 역할을 하고 있는지 알 수 있다.

Issues 보기

< 프로젝트의 공개 issues >

• pull request를 통해 현재 진행되고 있는 버그 수정과 기능을 알 수 있는 반면, issues를 통해서는 프로젝트에 필요한 작업을 넓은 관점에서 볼 수 있다.

• pull request는 주로 issue에 링크되어 있지만, 아무도 작업을 시작하지 않아 pull request가 없는 issue 또한 존재한다.

• issue 목록을 보기 위해 링크를 클릭하면 모든 공개 issue 목록이 자동으로 나타난다.

< 최근 issue >

• issue를 클릭하면 issue의 제목과 그 issue와 연관된 댓글을 볼 수 있다.

• 어떤 작업이 완료되어 GitHub로 푸쉬(push) 되었다면, 그리고 commit 메시지가 issue를 참조하고 있다면 무슨 작업이 행해졌는지 알 수 있게 issue 페이지를 보여준다.

Pulse 보기

< 부트스트랩의 pulse >

• pulse는 프로젝트에 대한 최근의 활동 내용을 엿볼 수 있는 좋은 방법이다.

• 위 그림 오른쪽에서 pulse를 최종일, 3일, 1주, 또는 한 달 등의 기간으로 지정할 수 있다.

• pulse는 병합되거나 추가된 pull request의 수를 먼저 표시한다. 또한 얼마나 많은 issue가 마감되고 개설되는지 표시한다.
  pulse가 활성화된 pull request와 issue의 수를 언급할 때 이 것이 단지 각각의 개수를 말하는 것 아니라 사용자가 지정한 시기에 개설되고 마감된 request와 issue의 수를 말하는 것임을 이해하는 것이 중요하다.

• 예를 들어, 이책을 작성할 시기에 부트스트랩은 지난주에 총 13개의 "활성화된" pull request가 있었는데 그중에 5개가 병합되고, 8개가 아직 논의가 되고 있다. 하지만 총 75개의 공개 pull request를 갖고 있다.

• 다음에 나오는 단락은 최근의 변경 내용을 간략히 요약한 것으로 개발자의 수, 마스터의 commit 수, 전체 브랜치의 총 commit 수, 마스터 브랜치에서 추가되거나 삭제 또는 수정된 파일의 수를 나열하고 있다.
  그리고 추가되거나 삭제된 콘텐츠의 라인 수를 표시하는데, 파일에서 텍스트 라인이 하나 수정되면 Git은 한 라인이 삭제되고 그 자리에 다른 라인이 추가 된 것으로 인식하는 것을 알아야한다.

• 오른쪽에는 지정된 시기에 commit을 가장 많이 생성한 기여자(contributor)를 막대그래프로 나타낸다.
  그 아래에는 병합되고 논의되고 있는 pull request의 제목과 마감되고 개설된 issue를 나타낸다.

• pulse는 "Unresolved conversations"로 표시되는 목록으로 끝나는데 이는 새롭게 추가된 댓글이 있으나 아직 마감되지 않는 모든 issue와 pull request의 목록을 말한다.

GitHub 그래프 보기

• puse가 최근의 활동내용을 요약해서 알려주는 반면, 그래프 화면은 좀 더 긴 기간 동안 프로젝트에 행한 작업을 알 수 있게 해준다.

기여자(contributor) 그래프

< 부트스트랩의 기여자(contributors) 그래프 >

• 위 그림 기여자 그래프는 일정 기간동안의 commit 수, 추가 또는 삭제 수에 근거해 기여자들을 보여준다.

• 전체 공헌 활동에 대한 그래프가 먼저 나오고, 뒤이어 각 개발자들의 공헌을 나타내는 작은 그래프가 가장 많이 공헌한 개발자 순으로 나온다.

• 기본 commit 그래프는 일정 기간 동안 마스터 브랜치에 만들어진 commit의 수를 나타낸다.
  마스터 브랜치에 병합된 commit만을 나타낸다는 것을 반드시 알아두자.

• 피처 브랜치(feature branch)에 일주일 내내 작업을 했는데 아직 그 작업이 병합되지 않았다면, 배포 준비가 되어 마스터 브랜치로 병합되어서야 비로소 공헌내용을 볼 수 있을 것이다.

< 2013년 여름의 기여자(contributors) 그래프 >

• 기본적으로 프로젝트의 전체 기간에 대한 그래프를 나타낸다.

• 좀 더 짧은 기간을 원한다면, 메인 그래프에서 원하는 시작점을 클릭하고 정하고 싶은 종료 시점까지 드래그하여 새로운 그래프를 만들 수 있다.
  위 그림은 2013년 여름의 commit에 중점을 두고 이 작업을 한일에서 9월2일로 집중되어 있음을 알 수 있다.

• 기여자 개인 별 commit 그래프는 commit 수와 그 기간동안 어떻게 분산되었는지 나타낸다.

• commit 에 정해진 기준은 없다.
  개발자들이 오류를 조사하거나 무언가를 테스트하지 않고 코드를 작성한다면 5-10분마다 commit을 생성할 것이다.
  그러나 팀에 따라서 어떤 개발자드은 비슷한 시간을 작업해도 다른 사람보다 훨씬 적은 수의 commit을 생성한다.
  이 경우라면 기여자 그래프의 "contribution type"을 추가 또는 삭제로 바꾸는 것이 좋겠다.
  이렇게 하면 개발자들이 프로젝트에서 추가하거나 삭제한 코드의 라인수를 알아낼 수있다.
  개발자들이 라인을 수정하면 이전 라인을 삭제하고 새로운 라인이 추가된 것으로 나타날 것이다.

Commit 그래프

< 부트스트랩에 대한 commit 그래프 >

• 위 그림 commit 그래프는 프로젝트 전 기간에 걸쳐 매주 얼마나 많은 commit이 발생했는지 나타내는데 활동이 얼마나 활발했는지 그리고 어떻게 달라졌는지 대략적인 추측을 해 볼 수있다.

• commit 그래프를 살펴보는 첫 번째 이유는 매주 얼마나 많은 commit이 발생했는지 알 수 있기 때문이다.
  일주일 간 발생한 commit 수를 하나의 막대로 나타낸 막대그래프를 먼저 표시한다.
  주기적인 또는 장기적인 동향을 알아보는 좋은 방법이다.

• " 프로젝트의 commit 수가 서서히 감소하는가? "
• " 개발자 수가 많으면 commit 수가 지속적으로 증가하는가? "
• " 대부분의 commit이 매달 마직막 주에 발생하는가? "
• " 아니면 계절적 추세인가? "

• 이 그래프는 commit 수가 일정 기간 동안 어떻게 변하고 있는지 잘 보여주어 생산성을 대략 추축해볼 수있다.

• 막대그래프 아래는 매주 요일별 평균 commit 수를 나타내는 선 그래프이다.
  이 그래프는 요일별 평균 규칙을 엿볼 수 있다.

• " 월요일에는 회의가 많기 때문에 commit 하지 않는가? "
• " 금요일 데모(demo) 날이라 전날인 목요일에 대부분 commit을 작성하는가? "
• " 아니면 장기간 지속하기에는 좋지 않지만 주말에 지나치게 맣이 작업하는가? "

Code Frequency 그래프

< 부트스트랩의 code frequency 그래프 >

• 위 그림의 code frequency 그래프는 일정 기간에 프로젝트에 추가되고 삭제된 코드줄 수를 보여주며, 특히 코도에 콘 변화가 있을 때 이를 식별하는 데 매우 유용하다.

• code frequency 그래프를 통해 프로젝트에 큰 변화가 언제 생겼는지 쉽게 파악할 수 있다.

• 개발자들이 대규모의 리팩토링을 할 때는 commit마다 몇 백 또는 볓 천의 코드줄을 추가하고 삭제한다.
  반면 일반적인 비즈니스에서는 commit이 몇 줄만 추가되거나, 수정 또는 삭제 된 코드를 포함한다.
  이러한 대규모 리팩토링의 경우 commit 수는 많이 변경되지 않을 수도 있지만 추가되고 삭제되는 줄 수는 급증하다.
  따라서 코드에 콘 변화가 생겼는지 알고 싶다면 code frequency 그래프를 살펴보면 된다.

• 예를 들어 위 그림 에서 대규모의 리펙토링이 수행된 것은 2013년 2월과 3월임을 알 수 있다.

Punch Card 그래프

< 부트스트랩의 punch card 그래프 >

• 위 그림 punch card 그래프는 무슨 요일, 몇 시에 대부분의 commit이 일어났는지 나타낸다.

• punch card 그래프는 일주일 동안 매일 매시간을 원으로 나타낸다.

• 원의 크기는 해당시간에 프로젝트에 만들어진 commit이 차지하는 비율을 나타낸다.

• 원이 클수록 그 시간에 commit이 많이 만들어졌다는 뜻이다.
  다시 말하면, 작업팀이 언제 가장 생산성이 높은지 엿 볼 수 있는 좋은 방법이 된다.

멤버(Members)목록

< 멤버(members) 목록 >

• 접근 권한에 상관없이 볼 수 있는 마지막 그래프는 멤버 목록이다.

• 만약 fork의 수가 평소와 다르다면 위 그림에 나타난 것과 같은 메시지가 나타나고 일부의 멤버 목록만이 표시된다.

• 멤버 목록은 누가 리포지토리를 fork 했는지 보여준다.

• 이들은 초기 parent 리포지토리의 협력자가 아니기 때문에 pull request를 이용해 기여하려면 리보지토리 복사본이 필요하다.