Git
Git이란, 버전 관리 시스템(VCS)로서, 로컬 환경에서 소스코드의 버전을 추적하고 관리하는 시스템.
Git 구성요소
-
Working Directory
- 사용자가 작업하는 공간
-
Staging Area
- 사용자의 작업을 임시 저장하는 공간
-
Git Directory (Local Repository)
- 작업 내용을 사용자 컴퓨터 환경(local)에 저장하는 공간
간단한 예시로 공책에 작성한 글을 블로그에 올린다고 하겠습니다.
- 공책에 손글씨로 작업을 한다.
- 공책에 작성한 작업을 카메라로 찍는다.
- 카메라에 저장된 사진을 블로그에 올린다.
공책에서의 작업은 직접 작업하는 공간이므로 Working Directory, 카메라는 작업을 임시적으로 저장하는 공간이므로 Staging Area, 블로그는 Git Directory로 구분할 수 있습니다.
Repository
모든 작업 이력이 저장되어있는 저장공간입니다.
각 작업들을 구분하고 관리하기 위해 작업들은 해시값으로 식별합니다.
-
Local Repository
- 로컬 버전의 프로젝트 저장공간
- 자신의 컴퓨터 환경에 저장
-
Remote Repository
- 외부 버전의 프로젝트 저장공간
- 자신의 프로젝트 뿐만 아니라, 다른 사용자들의 버전을 공유하고 관리되는 공간
Branch
특정 작업을 하기 위해 기존 흐름에서 분리되어 새로운 작업을 수행하는 흐름.
특정 브랜치에서 다른 작업을 수행하기 위해 새로운 작업 브랜치를 생성해 작업하고, 기존 브랜치에 다시 병합할 수 있습니다.
Commit
현재 작업의 상태를 저장하기 위한 작업.
Staging Area상태로 저장되어 있는 작업을 Local Repository에 저장시켜줍니다.
commit시 작업의 버전을 Hash코드로 저장하게 되고 commit 내역을 확인할 수 있습니다.
(git log 명령시)
Merge
분리되었던 브랜치의 작업이나 외부 버전의 작업을 현재 Head가 가리키는 버전에 병합하는 작업.
Pull
외부 저장소의 버전 코드를 로컬에 불러와 변경여부를 확인하고 병합시키는 작업.
Fetch와 Merge가 함께 수행됩니다.
Fetch
다른 버전을 현재 버전과 비교하여 변경점이 없는지 확인하는 작업으로 코드에 직접적으로 영향을 주지 않습니다.
Reset
Commit했던 작업을 취소시키기 위한 작업으로서, soft, mixed, hard 옵션이 있습니다.
-
soft- Local Repository에서 Reset하는 버전으로 Head가 가리키고 나머지(Staging Area, Working Directory)는 기존 작업을 유지하고 있습니다.
- Reset하는 버전과 현재 작업을 합쳐서 새로운 버전을 만들때 사용.
-
mixed- Local Repository의 Head와 Staging Area를 특정 버전으로 Reset하고 나머지 (Working Directory)는 기존 작업을 유지하고 있습니다.
- 현재 작업을 유지한채로 Reset 버전과 함께 add하고 싶을때 사용.
-
hard
- Local Repository, Staging Area, Working Directory가 Reset버전으로 변경되며, 현재 작업이 모두 삭제됩니다.- Reset 버전부터 새로 작업하려고 할때 사용.
예를 들어 총 3개 버전의 작업이 있다고 하겠습니다. (최신순으로 file.txt v3, file.txt v2, file.txt v1)
그렇다면 현재 Local Repository(Head), Staging Area(Index), Working Directory는 모두 최근 버전인 file.txt v3을 가리키고 있습니다.
Soft
Reset하려는 버전으로 Local Repository의 Head만 이동시킨다.
Staging Area, Working Directory는 기존 버전을 유지하고 있어 현재 작업을 합쳐 새로운 버전을 생성할 수 있습니다.
Mixed
Local Repository의 Head뿐만 아니라 Staging Area까지 Reset버전으로 되돌립니다. 즉, add까지 reset시킨것으로 현재 작업과 Reset버전이 새로운 add작업을 수행하고자 할때 사용합니다.
Hard
Local Repository의 Head, Staging Area, Working Directory 전부 Reset 버전으로 되돌리는 작업으로, 현재 작업까지 모두 사라지게 됩니다. (아주 조심하게 사용해야할 작업입니다.)
지금까지 했던 작업을 없었던 일 처리하고 Reset 버전부터 다시 작업하고자 할때 사용합니다.
GitHub
GitHub란 Git Repository를 위한 웹 기반 호스팅 서비스로서, 클라우드 서버를 이용하여 로컬에서 관리한 소스코드를 공유하고 다른 사람의 코드와 함께 관리할 수 있는 저장공간입니다.
주로 분산 버전관리, 엑세스 제어, 코드 공유 등의 기능을 제공하는 저장공간으로 사용됩니다.
GitFlow
여러 개발자가 동시에 여러 작업을 수행하기 위해 브랜치를 생성하는 경우, 작업의 흐름을 정리해서 효율적으로 협업하기 위한 방법입니다.
아래는 GitFlow를 잘 나타내는 이미지라고 생각합니다.
- main
- 기준이 되는 브랜치로 제품을 배포하는 브랜치입니다.
- develop
- 개발 브랜치로서, 해당 브랜치를 기준으로 다양한 작업 브랜치를 생성하여 작업하고 병합합니다.
- feature
- 단위 기능을 개발하는 브랜치로서, 기능 개발이 완료되면 develop브랜치로 병합합니다.
- release
- 이번 버전의 배포를 위한 브랜치로서, 기능 QA등을 수행할때 사용합니다.
- hotfix
- Main 브랜치에서 긴급한 이슈가 발생했을 때 사용하는 브랜치입니다.
Git History
Git을 사용해서 협업하게 된다면, develop브랜치를 기준으로 브랜치가 파생되고 병합되게 됩니다. 이때, 각 작업들의 commit로그가 저장되게 되는데, 단지 pull, commit으로만 작업하게 된다면 작업의 흐름을 파악하기 어려울 뿐만아니라 가독성이 나빠지게 됩니다.
이를 조금이나마 원활하게 하기 위해서 다양한 방법이 있습니다.
Rebase
파생된 브랜치에는 파생된 지점을 가리키는 base라는 지점이 있습니다.
아래에는 main의 c1지점에서 branch2, branch3의 브랜치가 파생되었습니다.
branch2 브랜치가 먼저 작업이 끝나서 main에 merge가 되고 그 다음으로 branch3 브랜치가 작업이 끝나 main으로 merge가 된다면 결과는 아래와 같습니다.
브랜치가 몇개 없어서 괜찮아 보일 뿐이지 여러개의 브랜치가 main에 하나씩 merge된다면 굉장히 복잡해 보일것입니다.
이 때, rebase기능을 사용하게 되면 조금더 가독성있고 정렬되게 git을 사용할 수 있습니다.
(branch2와 branch3의 base는 파생지점인 c1입니다.)
branch2의 작업이 먼저 끝난경우 main브랜치에 머지를 해줍니다.
다음 branch3가 작업을 하는 도중 branch2의 작업이 완료가 된 경우, base지점을 옮겨 해당 base부터 작업하여 main에 merge하는것처럼 정렬이 됩니다.
branch2와 main이 merge된 버전인 c7에 rebase 하게 되면 branch3은 c7을 base로 놓고 새로운 작업이 수행된것으로 정렬되게 됩니다.
이렇게 rebase를 잘 사용해주게 된다면 아래와 같은 복잡한 git branch를
아래와 같이 정리해 줄 수 있게됩니다.
Squash & Reward
- Squash
- 하나의 브랜치에서 여러 커밋으로 분리되어 있는 경우, 커밋들을 합쳐 git flow를 정리
- Reward
- 커밋 내용을 유지한채 커밋 메시지만 변경
Git 연습
https://learngitbranching.js.org/?locale=ko
나름 재밌습니다.
Reference
