티스토리 뷰
Git
특징
- 버전 관리 시스템으로 GitHub에서는 Git으로 관리하는 프로젝트를 올려둘 수 있다.
- 기업의 핵심 자산인 소스 코드를 올려두면 시/공간의 제약 없이 협업할 수 있고 프로젝트를 공개 저장소로 만들면 전 세계와 협업할 수 있다.
- 사본을 로컬에서 관리하기 때문에 GIT이 SVN에 비해 훨씬 빠르다.
- 변경을 쉽게 되돌릴 수 있고 두 버전의 소스 코드를 비교하는 일이 가능하다.
- 협업하고 있는 코드를 저장할 서버를 웹 호스팅 서비스 기능을 통해 자동으로 작업을 실행하게 할 수 있다. (pull, push)
장점
- branch를 통해 개발한 뒤 본 프로그램에 합치는 merge로 개발을 진행할 수 있다.
- 분산 버전관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있고 중앙 저장소가 날아가도 원상복구 가능하다.
- 체계적인 개발이 가능해지고 프로그램이나 패치를 배포하는 과정도 간단해진다. (pull로 업데이트, patch로 파일 배포)
관련 용어
- Repository : 저장소를 의미하며, 저장소는 히스토리, 태그, 소스의 가지치기 혹은 branch에 따라 버전을 저장한다. 저장소를 통해 작업자가 변경한 모든 히스토리를 확인 할 수 있다.
- Working Tree : 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점.
- Staging Area : 저장소에 커밋하기 전에 커밋을 준비하는 위치.
- Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업.
- Head : 현재 작업중인 Branch를 가리킨다.
- Branch : 가지 또는 분기점을 의미하며, 작업을 할때에 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 싶을때 Merge를 하여 작업을 한다.
- Merge : 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미한다.
명령어
- git init: 버전관리 하고 싶은 폴더에서 초기화를 하는 준비
- git add
- git commit: 수정 작업이 끝났음을 알리는 작업
- git pull: 원격 저장소의 변경된 내용을 로컬 저장소에 적용하는 작업
- git branch: 독립적인 공간을 만든다.
- git fork: 다른 사람의 Git 저장소에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 저장소를 내 Git 저장소로 그대로 복제하는 기능이다.
- git pull request: 저장소로 fork한 뒤, fork한 저장소에서 변경 사항을 가지고 원래 저장소의 소유자에게 merge를 요청하는 것이다.
=> 원본 저장소 소유자에게 코드 변경 사항을 알리는 기능
- git fetch: 원격저장소에 있는 변경내역들을 로컬저장소로 pull 하기 전에 변경된 내역들만 가져와서 확인시켜주는 기능
=> pull 하기 전에 변경 내역에 대한 로그를 확인하고 신중히 결정할 수 있는 기능
* Local에서 push하고, 원격저장소에서 원본저장소로 pullRequest를 하고, Local에서 원본저장소의 내용을 한번에 pull 할 수 있다.
Distributed Development
- 전체 개발 이력을 각 개발자의 로컬로 복사본을 제공하고 변경된 이력을 다시 하나의 저장소로 복사한다.
Strong support for non-linear development
- 신속하고 편리한 branch 및 merge 지원, 비선형 개발 이력을 시각화하고 탐색 할 수 있는 강력한 도구를 제공한다.
Efficient handling of large projects
- 매우 빠르고 대형 프로젝트나 이력이 많은 작업에 경우 합리적이다.
Cryptographic authentication of history
- Git 이력은 성공한 개발이력의 commit에 의해 개정명으로 저장되며 일단 이것이 배포되면 예전버전으로 변경하는 것은 불가능하며 암호화 할 수 있다.
Toolkit design
- 소규모 도구 모음으로 많은 스크립트들이 기능 보강을 제공한다.
Git-Flow
master
- 기준이 되는 브랜치로 제품을 배포하는 브랜치
develop-feature(하나의 기능 개발 시 만드는 브랜치)
- 개발자들이 이 브랜치를 기준으로 각자 작업한 기능을 merge
feature
- 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 merge
release
- 배포를 위해 master 브랜치로 보내기 전에 먼저 QA를 하기 위한 브랜치
hotfix
- master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치