-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git , Github, Gitlab #127
Comments
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Git이란?
컴퓨터 파일의 변경사항을 추적하고 여러명의 사용자들 간에 해당 파일들에 대한 작업을 조율하기 위한 분산 버전 관리 시스템입니다. 깃을 통해 다음과 같은 작업들을 할 수 있습니다.
버전관리 시스템의 필요성
편집이 빈번하게 일어나는 텍스트 파일을 관리한다고 합시다. 파일의 편집 전 상태로 되돌아가도록 하기 위해서는 아래와 같이 파일을 관리해야 합니다.
이 처럼 파일을 관리하게 되면 어떤 파일이 최신 파일인지 어떤 부분이 변경된 것인지 관리하기가 매우 어려워지게 됩니다. 또한 하나의 문서를 여러 사람이 동시에 작성한다면 업데이트 되는 파일을 공유하는 것이 어려워지고 서로 정보를 덮어쓰는 일도 일어날 수 있습니다. 이러한 문제를 해결하기 위해 등장한 것이 바로 버전 관리 시스템입니다.
버전 관리 시스템의 종류
Git의 버전 관리방식
Git이 파일들의 변경사항을 버전별로 관리하기 위해서 파일들을 어떤 식으로 인식하고, 어떠한 단계로 관리하는지 알아봅시다.
1. Git의 3가지 영역(단계)
Git은 아래 세가지 작업영역으로 파일을 관리합니다.
2. Git의 3가지 상태
git은 파일의 변경사항 들을 버전별로 관리하기 위해서 파일들을 Committed, Modified, Staged 3가지 상태로 관리를 합니다.
3. Git File Status Lifecycle
git에 의해 관리되는 파일들을 라이프사이클 관점에서 살펴봅시다. Working Directory에 있는 파일들은 크게 Tracked 상태와 Untracked 상태로 분류됩니다. Tracked 상태는 좀 더 세부적으로 Unmodified, Modified, Staged 상태로 분류될 수 있습니다. Git의 파일들은 반드시 해당 4가지 상태중 하나의 상태를 가지게 되고, 4가지 상태를 반복적으로 순환합니다.
원격 저장소와 로컬 저장소
Git은 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공합니다.
평소에는 내 PC의 로컬 저장소에서 작업하다가 작업한 내용을 공개하고 싶을 때에 원격 저장소에 업로드 합니다. 물론 원격 저장소에서 다른 사람이 작업한 파일을 로컬 저장소로 가져올 수도 있습니다.
Github와 Gitlab
Github와 Gitlab 모두 분산 버전 관리 툴인 깃 저장소 호스팅을 지원하는 웹 서비스입니다. 원격 저장소를 제공하는 웹 호스팅 서비스라고 할 수 있습니다.
Git 프로세스와 명령어
Git Branch
여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없습니다.이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치(Branch)' 입니다.
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.
만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있습니다.
저장소를 처음 만들면, Git은 바로 'master'라는 이름의 브랜치를 만들어 둡니다. 이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다.
Git 브랜칭 전략
여러 사람이 다양한 브랜치를 생성하고 사용하게 되면 브랜치를 어떤 식으로 관리하고 생성할 것인지에 대한 약속이 필요합니다. Git 브랜치를 효과적으로 나누고 관리하는 전략들에 대해 알아봅시다.
Git-flow
Git-flow는 Git이 새롭게 활성화되기 시작하는 10년전 쯤에 Vincent Driessen이라는 사람이 만들어낸 브랜치 관리 전략으로 현재는 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론입니다.
Git-flow는 5가의 브랜치를 사용해서 운영합니다.
master : 기준이 되는 브랜치로 제품을 배포하는 브랜치(배포 가능한 상태만을 관리)
develop : 다음 출시 버전을 개발하는 브랜치(이 브랜치를 기준으로 각자 작업한 기능들을 Merge)
feature : 단위 기능을 개발하는 브랜치(개발이 완료되면 develop 브랜치에 Merge)
release : master 브랜치로 보내기 전에 QA를 하기위한 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
장점
단점
브랜치 가 많아 복잡하다.
안 쓰는 브런치가 있다. 그리고 몇몇 브런치는 애매한 포지션이다.
Github-flow
Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜칭 전략.
git 튜토리얼
실제 git의 사용법을 익히고 싶으시다면
Reference
The text was updated successfully, but these errors were encountered: