[ GitHub ] 소개

---

Git이란?

Git은 버전 관리 시스템이다. 버전 관리 시스템은 파일의 변경 내역을 계속 추적하도록 개발된 소프트웨어이다. 다시 말해 Git은 분산 버전 관리 시스템으로, Git으로 프로젝트를 개발하는 사람은 모두 현재 상태의 파일뿐만 아니라 그 프로젝트의 전체 이력을 가지고 있게 된다는 뜻이다.

GitHub란?

GitHub는 Git repository를 업로드 할 수 있는 web site를 말한다. GitHub는 다른 사람드로가의 협력을 매우 용이하게 해준다. repository를 공유할 수 있는 중앙저장소, 웹 기반 인터페이스, forking, pull requests, issues, wikis와 같은 기능을 제공하여 팀원들과 보다 효율적으로 변경안을 구체화하고 토론하며 검토할 수 있게 해준다.

---

Git을 왜 사용하는가?

- 설령 독자적으로 일한다 해도, 만약 문서 파일을 편집한다면 Git을 사용했을 때 장점이 아주 많다.

1. 변경 취소 기능 - 실수를 했을 경우 구 버전의 작업 파일을 보국해 이전 단계로 돌아갈 수 있다.

2. 모든 변경에 대한 완벽한 이력( history ) - 하루, 일주일, 한 달, 또는 일 년 전에 프로젝트가 어떤 형태였는지 알고 싶다면 구 버전의 프로젝트를 확인해 그 당시 파일의 상태를 정확히 볼 수 있다.

3. 변경한 이유 기록 - 왜 변경을 했는지 기억할 수 없을 때가 있다. Git의 커밋 메시지( commit message )를 이용하면 변경한 이유를 쉽게 기록할 수 있어 추후에도 참조할 수 있다.

4. 변경에 대한 확신 - 이전 버전으로의 보구기가 쉽기 때문에 자신을 원하는 대로 변경을 할 수 있다. 잘 되지 않으면 언제든 이전 버전으로 복귀하면 된다.

5. 여러 갈래의 history - 콘텐츠의 변경 내용을 테스트해보거나 다른 기능을 독립적으로 실험해 보기 위해 별도의 브랜치( branch )를 생성할 수 있다. 완료되면 변경 내용을 마스터 브랜치( master branch )로 병합할 수 있고, 잘 작동하지 않을 경우 삭제할 수 있다.

6. 충돌 해결 능력 - Git을 이용하면 여러 사람들이 동시에 같은 파일을 작업할 수 있다. Git은 대개 자동으로 변경 사항을 병합할 수 있다. 그렇지 못할 경우 충돌이 무엇인지 알려주고, 이를 해결하기 쉽게 해준다.

7. 독립된 history - 여러 사람들이 다른 브랜치( branch )에서 작업이 가능하다. 기능을 독립적으로 개발하고, 완료되었을 때 그 기능을 병합할 수 있다.

8. 기록 요구 - Issues를 사용해 버그를 기록하거나 개발하고 싶은 새로운 기능을 구체화할 수 있다.

9. 독립된 history에 대한 협력 - branch와 pull requests를 이용해 다른 branch 또는 기능에 협력할 수 있다.

10. 진행 중인 작업 검토 - pull requests 목록을 통해 현재 무슨 작업이 진행되고 있는지 모두 볼 수 있다. 그리고 특정 pull requests를 클릭하여 최근이 변경 내용과 변경에 관한 모든 논의 내용을 볼 수 있다.

11. 팀의 작업 진척 상황 확인 - 펄스( pulse )를 훑어보거나 커밋 히스토리( commit history )를 살펴보면 팀의 작업 진척 상황을 알 수 있다.

Git의 주요 개념

- Commit

하나 또는 다수의 파일에 변경 내용을 저장할 때마다 새로운 commit을 생성한다.

- Commit message

commit을 생성할 때마다 왜 변경을 하였는지에 대한 이유를 설명하는 메시지를 제공해야 한다. 이 commit message는 변경을 한 이유를 추후에 이해할 때 매우 유용하다.

- Branch

테스트를 해보거나 새로운 기능을 개발하기 위해 사용할 수 잇는 따로 떨어진 독립적인 commit을 말한다.

- Master branch

새로운 Git project를 만들 때마다 master라고 불리는 기본 branch가 생성된다. 배포할 준비가 되면 작업이 최종적으로 마무리되는 branch이다.

- Feature 또는 Topic

새로운 기능을 개발할 때마다 작업할 branch를 만드는데 이를 Feature branch 라고한다.

- Release branch

직업 QA( 품질보증 ) 작업을 하거나 고객의 요구로 구 버전의 소프트웨어를 지원해야 한다면 모든 수정이나 업데이트를 위한 장소로 릴리즈 브랜치가 필요하다. Feature branch와 release branch는 기술적인 차이는 없지만, 팀원들과 프로젝트에 대해 얘기할 때 확연히 구별할 수 있어 유용하다.

- Merge ( 병합 )

Merge는 한 branch에서 완성된 작업을 가져와 다른 branch에 포함하는 방법이다. 흔히 feature branch를 master branch로 병합한다.

- Tag

특정 이력이 있는 commit에 대한 참조. 어떤 버전의 코드가 언제 배포되었는지 정확히 알 수 있도록 제품 배포 기록에 가장 자주 사용된다.

- Check out

Project history의 다른 버전으로 이동해 해당 시점의 파일을 보기 위해 check out한다. 가장 일반적으로 branch에서 완료된 작업을 모두 보기 위해 branch를 check out 하지만, commit도 check out 할 수 있다.

- Pull request

원래  Pull request는 branch에서 완료된 작업을 다른사람이 리뷰하고 마스터로 병합하도록 요청하기 위해 사용되었다. 요즘은 개발 가능한 기능에 대한 논의를 시작하는 초기 작업 단계에서 자주 사용한다.

- Issue

GitHub는 기능에 대해 논의하거나 버그를 추적하거나 혹은 두 가지 경우 모두 사용될 수 잇는 Issue라는 기능을 갖고 있다.

- Wiki

워드 커닝햄( Ward Cunningham )이 최초로 갭라하였다. wiki는 링크들 간을 연결해 간단하게 웹 페이지를 만드는 방법이다. GitHub Project는 문서 작성에 wiki를 자주 사용한다.