[ GitHub 사용 설명서 ] Chapter-1. GitHub 소개

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

제목 : GitHub 사용 설명서

저자 : Peter Bell & Brent Beer

번역 : Ann Lee

소개 : bnitech.tistory.com/8

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

GitHub 사용 설명서

GitHub 소개

Git이란?

• 분산 버전 관리 시스템

• 버전관리 시스템이란 파일의 변경 내역을 계속 추적하도록 개발된 소프트웨어

• 프로젝트의 전체 이력을 가지게 된다.

GitHub란?

• Git 리포지리토리(repository)를 업로드  할 수 있는 웹사이트를 말한다.

• 다른 사람들과의 협력을 매우 용이하게 해준다.

• 리포지토리를 공유할 수 있는 중앙저장소, 웹 기반 인터페이스, forking, pull requests, issues, wikis와 같은 기능을 제공하여 팀원들과 보다 효율적으로 변경안을 구체화하고 토론하며 검토할 수 있게 해준다.

왜 Git을 사용하는가?

• 변경취소 기능

• 실수를 했을 경우 구버전의 작업 파일열을 복구해 이전 단계로 돌아갈 수 있다.

• 모든 변경에 대한 완벽한 이력

• 과거 프로젝트가 어떤 형태 였는지 알고 싶다면 구버전의 프로젝트를 확인해 그 당시 파일의 상태를 정확히 볼 수 있다.

• 변경한 이유 기록

• Git의 commit message를 통해 왜 변경한 이유를 쉽게 기록하 수 있어 추후에도 참조할 수 있다.

• 변경에 대한 확신

• 이전 버전으로의 복귀가 쉽기 때문에 자신을 원하는 대로 변경 할 수 있다.

• 여러 갈래의 히스토리

• 콘덴츠의 변경 내용을 테스트해보거나 다른 기능을 독립적으로 실험해 보기 위해 별도의 branch를 생성할 수 있다.

• 완료되면 변경 내용을 master branch로 병합하거나 삭제 할 수 있다.

• 충돌 해결 능력

• Git은 대개 자동으로 변경 사항을 병합할 수 있지만, 작업에 충돌이 생기면 알려주고, 이를 해결하기 쉽게 해준다.

• 독립된 히스토리

• 여러 사람들이 다른 branch에서 작업이 가능하다. 기능을 독립적으로 개발하고, 완료되었을 때 그 기능을 병합할 수 있다.

왜 GitHub를 사용하는가?

• 기록요구
• Issues를 사용해 버그를 기록하거나 개발하고 싶은 새로운 기능을 구체화 할 수 있다.
• 독립된 히스토리에 대한 협력
• branch와 pull request를 이용해 다른 branch 또는 기능에 협력할 수 있다.
• 진행 중인 작업 검토
• pull request 목록을 통해 현재 무슨 작업이 진행되고 있는지 모두 볼 수 있다.
• 특정 pull request를 클릭하여 최근 변경 내용과 변경에 관한 모든 논의 내용을 볼 수 있다.
• 팀의 작업 진척 상황 확인
• pulse를 훑어보거나 commit history를 살펴보면 팀의 작업 진척 상황을 알 수 있다.

주요 개념

• Commit
• 하나 또는 다수의 파일에 변경 내용을 저장할 때마다 새로운 commit을 생성한다.
• "이 변경 내용을 commit하고 이를 GitHub로 push 합시다"
• Commit Message
• commit을 생성할 때마다 왜 변경을 하였는지에 대한 이유를 설명하는 메시지를 제공해야 한다.
• "새로운 SEC 가이드라인에 대한 수잔의 의견을 commit 메시지에 꼭 넣으세요"
• Branch
• 테스트를 해보거나 새로운 기능을 개발하기 위해 사용할 수 있는 따로 떨어진 독립적인 commit들을 말한다.
• "새로운 검색 기능을 구현하기 위해 branch를 생성합니다."
• Master Branch
• 새로운 Git 프로젝트를 만들 때마다 master라고 불리는 기본 브랜치가 생성된다.
• 배포할 준비가 되면 최종적으로 마무리 되는 브랜치이다.
• "master로 바로 commit하면 안 된다는 것을 기억하십시오"
• Feature / Topic Branch
• 새로운 기능을 개발할 때마다 만들어 작업을 수행하는 branch
• "feature branch가 너무 많습니다. 이들 중 하나나 두 개를 완료해서 출시하는 데 주력합시다."
• Release Branch
• 직접 QA(품질보증) 작업을 하거나 고객의 요구로 구 버전의 소프트웨어를 지원해야 한다면 모든 수정이나 업데이트를 위한 장소로 사용
• feature branch와 release branch 기술적인 차이는 없지만 팀원들과 프로젝트에 대해 얘기할 때 확연히 구별할 수 있어 유용하다.
• "release branch 전체에 대한 보안 버그를 수정해야 합니다."
• Merge
• 한 브랜치에서 완성된 작업을 가져와 다른 브랜치에 포함하는 방법이다.
• 흔히 feature branch를 master branch로 병합한다.
• "'내 계정' 기능이 훌륭합니다. 배포할 수 있게 마스터로 병합해 줄 수 있겠습니까?"
• Tag
• 특정 이력이 있는 commit에 대한 참조
• 어떤 버전의 코드가 언제 release되었는지 정확히 알 수 있도록 제품 배포 기록에 가장 자주 사용된다.
• "이번 배포판에 태그를 달고 출시합시다."
• Check out
• 프로젝트 history의 다른 버전으로 이동해 해당 시점의 파일을 보기 위해 사용
• 브랜치에서 완료된 작업을 모두 보기 위해 브랜치를 check out 하지만, commit도 check out 할 수 있다.
• "최종 릴리즈 태그를 check out 해주시겠어요?"
• Pull request
• 원래 브랜치에서 완료된 작업을 다름 사람이 리뷰하고 마스터 병합하도록 요청하기 위해 사용되었다.
• 요즘은 개발 가능한 기능에 대한 논의를 시작하는 초기 작업 단계에서 자주 사용된다.
• "다른 팀원들이 어떻게 생각하는지 알 수 있게 새로운 투표 기능에 대한 pull request를 만드십시오"
• Issue
• 기능에 대해 논의하거나 버그를 추적하거나 혹은 두 가지 경우 모두 사용될 수 있다
• "당신이 옳아요. 아이폰에서는 로그인이 되지 않네요. 버그를 검증하기 위한 단계를 기록하면서 GitHub에 Issue를 생성해 주시겠습니까?"
• Wiki
• 워드 커닝햄(Ward Cunningham)이 최초로 개발하였다.
• wiki는 링크들 간을 연결해 간단하게 웹페이지를 만드는방법이다.
• GitHub 프로젝트는 문서 작성에 wiki를 자주 사용한다.
• "복수의 서버에서 작동하게끔 프로젝트 환경 설정 방법을 설명하는 페이지를 추가해 주시겠습니까?"
• Clone
• 종종 로컬로 작업하기 위해 프로젝트 복사본을 GitHub에서 다운로드 한다.
• repository를 사용자의 컴퓨터로 복사하는 과정을 cloning이라고 한다.
• "리포지토리를 복제하고, 버그를 수정한 다음 오늘 밤 수정본을 다시 GitHub로 push 해주시겠습니까?"
• Fork
• 때로는 프로젝트를 직접 변경하는 데 필요한 권한을 보유하지 못할 때가 있다. 잘 알지 못하는 사람이 작성한 오픈소스 프로젝트이거나, 회사에서 작업을 같이 많이 하지 않는 다른 그룹이 작성한 프로젝트일 수도 있다. 그러한 프로젝트를 변경하고 싶다면 먼저 GitHub의 사용자 계정에 프로젝트 복사본을 만들어야 한다.
• 이 과정을 리포지토리를 fork 한다고 한다.
• 그런 다음 clone하고 , 변경하며, pull request를 이용해 원본 프로젝트에 변경 내용을 반영할 수 있다.
• "홈페이지 마케팅 원고를 당신이 어떻게 재작성 했는지 보고 싶습니다. 리포지토리를 fork하고 수정안과 함께 pull request를 제출해주십시오."

Git과 GitHub의 차이를 알아야한다