-
Git이란?
- Git은 버전 관리 시스템
- 파일의 변경 내역을 계속 추적하도록 개발 된 소프트웨어
- Git으로 프로젝트를 개발하는 사람은 모두 현재 상태의 파일뿐만 아니라 그 프로젝트의 전체 이력을 가지고 있게 된다.
GitHub란?
- GitHub는 Git 리포지토리를 업로드 할 수 있는 웹사이트를 말한다.
- 리포지토리를 공유할 수 있는 중앙저장소, 웹 기반 인터페이스, forking, pull requests, issues, wikis와 같은 기능을 제공하여 팀원들과 보다 효율적으로 변경을 구체화하고 토론하며 검토할 수 있게 해준다.
Git을 사용하는 이유?
- 변경 취소 기능
실수를 했을 경우 구 버전의 작업 파일을 복구해 이전 단계로 돌아갈 수 있다.
- 모든 변경에 대한 완벽한 이력(history)
하루, 일주일, 한 달, 프로젝트가 어떤 형태였는지 알고 싶다면 구 버전의 프로젝트를 확인해 그 당시의 파일 상태를 확인할 수 있다.
- 변경한 이유 기록
Git 커밋 메시지를 이용하면 변경한 이유를 쉽게 기록할 수 있어 추후에도 참조할 수 있다.
- 변경에 대한 확신
이전 버전으로 복귀가 쉽기 때문에 자신을 원하는 대로 변경을 할 수 있다. 잘 되지 않으면 언제든 이전 버전으로 복귀하면 된다.
- 여러 갈래의 히스토리(history)
콘텐츠 변경 내용을 테스트해보거나 다른 기능을 독립적으로 실험해 보기 위해 별도의 브랜치를 생성할 수 있다.
완료되면 변경 내용을 마스터 브랜츠로 병합할 수 있고, 잘 작동하지 않을 경우 삭제할 수 있다.
- 충돌 해결 능력
Git을 이용하면 여러 사람들이 동시에 같은 파일을 작업할 수 있다.
Git은 재개 자동으로 변경 사항을 병합할 수 있다. 그렇지 못하면 충돌이 무엇인지 알려주고 이를 해결하기 쉽게 해준다.
- 독립된 히스토리(history)
여러 사람들이 다른 브랜치에서 작업이 가능하다. 기능을 독립적으로 개발하고, 완료되었을 때 그 기능을 병합할 수 있다.
GitHub를 사용하는 이유?
- 기록 요구
Issues(이슈)를 사용해 버그를 기록하거나 개발하고 싶은 새로운 기능을 구체화할 수 있다.
- 독립된 히스토리(history)에 대한 협력
브랜치와 pull request를 이용해 다른 브랜치 또는 기능에 협력할 수 있다.
- 진행 중인 작업 검토
Pull request목록을 통해 현재 무슨 작업이 진행되고 있는지 모두 볼 수있다. 그리고 특정 pull request를 클릭하여 최근의 변경 내용에 대한 모든 논의 내용을 볼 수 있다.
- 팁의 작업 진척 상황 확인
펄스(pulse)를 훑어보거나 커밋 히스토리(commint history)를 살펴보니 팀의 작업 진척 상황을 알 수 있다.
주요개념
- Commit
하나 또는 다수의 파일에 변경 내용을 저장할 떄마다 새로운 commit을 생성한다.
- Commit 메시지
Commit을 생성할 때마다 왜 변경을 하였는지에 대한 이유를 설명하는 메시지를 제공해야 한다.
- 브랜치(branch)
테스트를 해보거나 새로운 기능을 개발하기 위해 사용할 수 있는 따로 떨어진 독립적인 commit들을 말한다.
- 마스터 브랜치(master branch)
새로운 Git 프로젝트를 만들 때마다 master라고 불리는 기본 브랜치가 생성된다. 배포할 준비가되면 작업이 최종적으로 마무리되는 브랜치이다. (마스터는 바로 commit 하면 안 된다는 것을 기억하자~!)
- 피처(feature, 또는 토픽(topic)브랜치
새로운 기능을 개발할 때마다 작업할 브랜치를 만드는데 이를 피처 브랜치(feture brach)라고 한다.
- 릴리즈 브랜치(release branch)
직접 QA(품질보증)작업을 하거나 고객의 요구로 구 버전의 소프트웨어를 지원해 한다면 모든 수정이나 업데이트를 위한 장소로 릴리즈 브랜치가 필요하다. 피처 브랜치와 차이는 없지만, 팀원들과 프로젝트에 대해 얘기할 때 확연히 구분할 수 있다.
- 병합(Merge)
병합은 한 브랜치에서 완성된 작업을 가져와 다른 브랜치에 포함하는 방법이다. 흔히 피처 브랜치를 마스터 브랜치로 병합한다.
- 태그(tag)
특정 이력이 있는 commit에 대한 참조, 어떤 버전의 코드가 언제 배포되었는지 정확히 알 수 있도록 제품 배포 기록에 가장 자주 사용된다.
- 체크아웃(Check out)
프로젝트 history의 다른 버전으로 이동해 해당 시점의 파일을 보기 위해 check out한다. 가장 일반적으로 브랜치에서 완료된 작업을 위해 브랜치를 check out 하지만, commit도 check out할 수 있다.
- Pull request
원래 pull request는 브랜치에서 완료된 작업을 다른 사람이 리뷰하고 마스터로 병합하도록 요청하기 위해 사용되었다. 요즘은 개발 가능한 기능에 대한 논의를 시작하는 초기 작업 단계에서 자주 사용한다.
- Issue
Github는 기능에 대해 논의하거나 버그를 추적하거나 혹은 두 가지 경우를 모두 사용될 수 있는 issues라는 기능을 갖고 있다.
- Wiki
Wiki는 링크들 간을 연결해 간단하게 웹 페이지를 만드는 방법이다.
- 복제(Clone)
로컬로 작업하기 위해 프로젝트 복사본을 Github에서 다운로드 한다. 리포지토리를 사용자의 컴퓨터로 복사하는 과정을 복제라고 한다.
- Fork
프로젝트를 직접 변경하는 데 필요한 권한을 보유하지 못할 때가 있다. 잘 알지 못하는 사람이 작성한 오픈 소스 프로젝트이거나 회사에서 작업을 같이 많이 하지 않는 다른 그룹이 작성한 프로젝트일 수 있다. 그러한 프로젝트를 변경하고 싶다면 먼저 Github의 사용자 계정에 프로젝트 복사본을 만들어야 한다. 그 과정을 리포지토리를 fork한다고 한다. 그런 다음 복제하고, 변경하며, pull request를 이용해 원본 프로젝트에 변경 내용을 반영할 수 있다.