깃(Git) 개념(버전 관리 시스템 - VCS)과 명령어 정리(CLI)

1. 깃(Git) 이란?

깃(Git)은 2005년에 리누스 토르발스에 의해 개발된  '분산 버전관리 시스템(Distributed Version Control Systems - DVCS)' 으로, 컴퓨터 파일의 변경사항을 추적하고 여러명의 사용자들 간에 파일에 대한 작업을 조율하는데 사용된다.

 

주로 여러 명의 개발자가 하나의 소프트웨어 개발 프로젝트에 참여할 때 소스 코드를 관리하는데 주로 사용

 

2. 버전 관리란?

버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다.

각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다.

 

즉,  버전 관리 시스템을 이용하면 큰 노력없이 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다.

 

1) 로컬 버전 관리(local VCS) - 로컬 컴퓨터의 DB를 사용해서 파일의 변경 정보 관리

2) 중앙집중식 버전 관리(CVCS) - 파일을 관리하는 중앙 서버에서 클라이언트가 파일을 받아서 사용 
    ex) CVS, SVN

3) 분산 버전 관리(DVCS) 

 

2-1. 분산 버전 관리 시스템 (Distributed Version Control Systems)

저장소를 히스토리와 더불어 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. Clone은 모든 데이터를 가진 진정한 백업이다.

 

게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용할 수 있다.

 

내 디렉토리 안에 .git 디렉토리가 Version Database 이고 Git의 Repository가 서버의 Version Database가 되는 것.

 

3. 버전 관리는 왜 필요한가?

PPT 발표 자료를 만들 때를 가정하여 설명

 

처음에 발표자료.ppt 제목의 파일 만들었다가 수정이 추가 된 후 발표자료_최종.ppt 파일로 바꾸고, 또 추가된 수정을 거쳐 발표자료_찐최종.ppt 파일을 만들었다고 치면 이렇게 파일명을 바꿔서 각 버전을 관리하는 방법도 있겠지만, 개인이 아닌 다수가 참여하는 프로젝트의 파일을 관리할 때는 파일을 알아보기 어렵고 효율적이지 못할 뿐만 아니라 파일을 합치는 과정에도 매우 복잡할 것이다.

 

개발 프로젝트에서 이런 버전관리를 돕는 시스템이 바로 깃(git)이다.

 

3-2. git은 왜 사용하는가(장점)?

깃 제작자 Linux 개발 커뮤니티(특히 Linux 창시자 Linus Torvalds) 의 목표

• 빠른 속도 - 모든 작업이 대부분 로컬에서 진행된다.
• 단순한 구조
• 비선형적인 개발(수천 개의 동시 다발적인 개발과 공유)
• 완벽한 분산 - clone된 프로젝트에서 동시에 작업 진행 가능, 사용자들은 메인 코드 전체를 가지고 있기 때문에 서버가 다운되는 등의 문제가 발생했더라도 문제 발생 X, 
• Linux 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)
• 데이터의 무결성 보장 - checksum 으로 검사를 거치게 된다 Commit ID -> Version history 관리
• 오픈 소스

-> 효율적인 협업 방법 / 버전 backup 가능

 

4. git 의 특징

가지 치지(Branch)와 병합(Merge)

 

사용자는 메인 코드에서 가지를 생성해서 독립성을 유지한 태로 개발을 진행할 수 있습니다. 이는 다양한 코드를 개발 또는 테스트 해 볼 수 있는 환경을 제공해줍니다.

여러 가지를 만들어 개발 또는 테스트를 진행할 수 있고 이후 병합을 통해 메인 코드에 반영을 하거나 삭제할 수 있습니다.

가지는 일 단위의 작업이 될 수도 있고, 기능이 될 수도 있습니다. 사용하기 나름입니다.

 

다른 VCS를 사용하던 경험을 버려야 한다. Git은 미묘하게 달라서 다른 VCS에서 쓰던 개념으로는 헷갈린다. 사용자 인터페이스는 매우 비슷하지만, 정보를 취급하는 방식이 다르다. 이런 차이점을 이해하면 Git을 사용하는 것이 어렵지 않다.

 

Git은 commit 하거나 프로젝트의 상태를 저장할 때 마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일의 변경이 없다면 Git은 성능을 위해서 파일을 새로 저장하지 않고 이전 상태의 파일에 대한 링크만 저장한다. Git은 데이터를 스냅샷의 스트림처럼 취급한다.

 

거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요 없다. 대부분의 명령어가 네트워크의 속도에 영향을 받는 CVCS에 익숙하다면 Git이 매우 놀라울 것이다. Git의 이런 특징에서 나오는 미칠듯한 속도는 오직 Git느님만이 구사할 수 있는 전능이다. 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행된다.

 

서버의 접속에 구애받지 않고 자유롭게 이용할 수 있다.

 

Git은 데이터를 저장하기 전에 항상 체크섬을 구하고 그 체크섬으로 데이터를 관리한다. 그래서 체크섬을 이해하는 Git 없이는 어떠한 파일이나 디렉토리도 변경할 수 없다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학이다. Git 없이는 체크섬을 다룰 수 없어서 파일의 상태도 알 수 없고 심지어 데이터를 잃어버릴 수도 없다.

Git은 SHA-1 해시를 사용하여 체크섬을 만든다. 만든 체크섬은 40자 길이의 16진수 문자열이다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구한다. SHA-1은 아래처럼 생겼다.

24b9da6552252987aa493b52f8696cd6d3b00373

Git은 모든 것을 해시로 식별하기 때문에 이런 값은 여기저기서 보인다. 실제로 Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장한다.

 

5. git 기본 용어

• Repository : 저장소라고 불리며, 히스토리, 태그, 소스의 가지치기 혹은 branch에 따라 버전을 저장하고 작업자가 변경한 모든 히스토리를 확인 가능
  -  local repository : 내 PC에서 관리하는 git 저장소
  - remote repository : 로컬 저장소를 업로드 하는 저장소
• Workign Tree : 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점. 프로젝트의 특정 버전을 Checkout 한 것
• Staging Area (Index) : 저장소를 커밋하기 전에 커밋을 준비하는 위치
• Commit : 현재 변경된 작업 상태의 점검을 마치면 확정하고 저장소에 저장하는 작업
• Head : 현재 작업중인 Branch를 가리킨다.
• Branch : 가지 또는 분기점. 작업을 할 때에 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 싶을 때 Merge를 하여 작업을 한다.
• Merge : 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미한다.
  
• Working Directory : 현재 작업 중에 있는 폴더
  

6. git 을 사용하는 방법

• CLI
• GUI

Git의 모든 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능 중 일부만 구현하기 때문에 비교적 단순하다. CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는다. GUI를 사용하고 싶더라도 CLI가 기본으로 설치되는 도구

 

7. git 기본 명령어

• git help : 도움말 기능 (가장 많이 사용하는 21개의 깃 명령어 출력). 사용법이 궁금한 명령어에 대해 'git help [궁금한 명령어]' 를 입력하면 해당 깃 명령어의 설정과 사용에 대한 도움말 출력.
• git init : 깃 저장소를 초기화. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 그냥 일단 폴더이다. 이 명령어를 입력한 후에야 추가적인 깃 명령어 입력 가능. 폴더와 저장소를 이어줌
• git status : 저장소 상태 체크. 어떤 파일이 저장소 안에 있는지, 커밋이 필요한 변경사항이 있는지, 현재 저장소의 어떤 브랜치에서 작업하고 있는지 등의 상태정보 출력
• git branch : 새로운 브랜치 생성. 여러 협업자와 작업할 시, 이 명령어로 새로운 브랜치를 만들고 자신만의 변경사항과 파일 추가 등의 커밋 타임라인을 생성 완성 후 협업자의 branch 혹은 main 과 merge
• git add : 'staging 영역' 변경 내용 추가. 다음 commit 명령 전까지 변경 분을 staging 영역에 보관하여 변동 내역을 저장.

명령어	내용
git add [업로드 하고싶은 파일 혹은 디렉토리 경로]	해당 파일 혹은 디렉토리 변경 내용 staging area 등록
git add .	현재 디렉토리 모든 변경내용 staging area 등록

• git commit : staging area에 있는 변경 내용 묶음 및 정의
  ex) git commit -m [커밋 메세지] : staging area에 있는 내용은 "커밋 메세지"를 반영한 수정본 파일의 묶음
• git log : 커밋 내역 확인
• git push : 로컬에서 서버로 commit 한 변경 사항을 저장
• git pull : 서버 저장소로부터 최신 버전을 가져오기 - 작업 도중 기존 작업 내용은 유지하면서, 최신 코드로 업데이트 할 때 사용
• git clone : 서버 저장소의 데이터를 로컬 저장소로 복사. (서버 저장소의 데이터를 그대로 가져옴. 작업중이던 내역있을 시 덮어쓰게 됨)
• git checkout : 작업을 진행할 브랜치로 변경
  ex) git checkout dev : Head를 dev 브랜치로 변경
• git merge : 개별 branch에서 마친 작업을 master branch로 병합

 

8. Git Flow

git의 파일은 Committed, Modified, Staged  세 가지 상태로 관리한다.

• Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
• Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.
• Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.

이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다.

Git 디렉토리는 Git이 프로젝트를 모든 데이터를 저장하는 곳이다. 이 Git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어진다.

워킹 트리는 프로젝트의 특정 버전을 Checkout 한 것이다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만든다.

Staging Area는 Git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다. Git에서는 기술용어로는 “Index” 라고 하지만, “Staging Area” 라는 용어를 써도 상관 없다.

Git으로 하는 일은 기본적으로 아래와 같다.

1. 워킹 트리에서 파일을 수정한다.
2. Staging Area에 파일을 Stage 해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.
3. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.

Git 디렉토리에 있는 파일들은 Committed 상태이다. 파일을 수정하고 Staging Area에 추가했다면 Staged이다. 그리고 Checkout 하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified이다. Git의 기초에서 이 상태에 대해 좀 더 자세히 배운다. 특히 Staging Area를 이용하는 방법부터 아예 생략하는 방법까지도 설명한다.

 

Staging Area는 작업한 내용이 올라가는 임시 저장 영역이다. Working Directory에서 작업한 내용을 git add 명령어를 통해 Staging Area으로 이동하게 됩니다. Staging Area로 넘어온 작업 파일들은 git에 의해 변경점이 추적되고 관리됩니다.

예를 들어서 A라는 파일을 수정하여 git add를 통해 Staging Area에 올리게 되면, 파일의 상태가 원격 저장소와 내용이 다르다면, 내용이 다르다는 것을 표기해주는 것 입니다. 개발자는 이 영역에서 자신이 수정한 것들을 다시 한번 확인하고 원격 저장소와 비교할 수 있다.

 

Staging Area에 있는 파일들을 Local Repository로 이동하게 하려면 Commit을 합니다. Local Repository는  커밋들이 영구적으로 저장되는 영역이다. commit을 할 때 마다 local repository에 쌓이는 것이다.

또한 Commit을 할 때에는 메세지를 작성하게 되는데 협업 개발자들 간의 협의된 양식을 따르게 된다.

예를 들어서 

 

 

---

 

• 원격 저장소의 소스코드를 다운로드한다 (Clone)
• 작업 디렉터리에서 작업한 이후 스테이징 영역으로 추가한다 (add)
• 의미 있는 변경점이 쌓이면 확인 후 로컬 저장소에 저장한다 (commit)
• commit들을 원격 저장소로 옮기기 전에 원격저장소의 변경이 있었는지 확인하고, 변경점이 있다면 내용을 가져온다 (git pull)
• 충돌하는 부분이 있다면 팀원들과 협의하여 해결하고, 충돌하는 부분이 없다면 원격저장소로 commit들을 올린다 (git push)

9. (git을 잘 활용하는 법) Branch 전략

Branch란?
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.

 

Branch 전략이란?

여러 개발자가 협업하는 환경에서 git 저장소를 효과적으로 활용하기 위한 work-flow

브랜치의 생성,삭제,병합이 자유로운 git의 유연한 구조를 활용하여 다양한 방식으로 소스관리를 할 수 있다.

 

자주 쓰이는 브랜치 전략

•  git-flow - 5가지 브랜치를 이용해 운영하는 브랜치 전략
•  github-flow - master 브랜치와 Pull Request를 활용한 브랜치 전략
•  gitlab-flow
  
  

1. git-flow

 - 항상 유지되는 2개의 메인 브랜치와 역할을 완료하면 사라지는 3개의 보조 브랜치로 구성되어 있습니다.

 - 메인 브랜치 : 항상 유지

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치

- 서포팅 브랜치 : merge 되면 삭제

• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotflx : 출시 버전에서 발생한 버그를 수정하는 브랜치 (master로 부터 생성)

- 특징

• 배포 주기가 길고 팀의 여력이 있는 경우 적합
• 가장 유명한 전략인 만큼 많은 IDE가 지원 
• 많은 기업에서 표준으로 사용

- 개발 프로세스

• 개발자는 develop 브랜치로부터 본인이 개발하고자 하는 기능을 위한 feature 브랜치를 만듦
• feature 브랜치에서 기능을 만들다가, 기능이 완성되면 develop 브랜치에 merge 함
• 새로 개발된 기능들이 develop 브랜치에 모두 merge가 됐다면 QA나 테스트를 위해서 release 브랜치를 생성
• realese 브랜치에서 QA를 하다가 오류가 발생하면 release 브랜치 내에서 수정
• realese 브랜치에서 QA를 마쳤다면, 해당 버전을 배포하기 위해 master 브랜치로 merge 함
• bugfix가 있었다면 해당 내용을 반영하기 위해 develop 브랜치에도 merge 함
• 만약 배포 중인 프로그램 버전 (master) 에서 버그가 발생한다면 hotfix 브랜치를 만듦
• hotfix 브랜치에서 bugfix가 끝나면 develop과 master 브랜치에 각각 merge 함

* 버그 픽스(bug fix) : 컴퓨터 시스템 또는 프로그램 안에 존재하는 버그를 수정하여 정상적으로 작동하도록 만드는 작업

 

2. github-flow

 - 제품이 릴리즈되는 최신버전인  master 브랜치만 존재함

 - 특징

• 브랜치 전략이 단순하여 git을 처음 접하는 사람에게도 유용함
• CI(지속적 통합), CD(지속적 배포)가 자연스럽게 이루어짐.
• master에 merge가 일어나면 바로 배포하도록 설정을 해 주는 경우가 많음.

- 개발 프로세스

• master로 부터 기능 개발, 버그, 혹은 어떠한 이유로 수정할 일이 생기면 브랜치를 생성
• git-flow 처럼 체계적인 분류가 없기 때문에 브랜치 이름은 의도를 아주 잘 드러내도록 작성
• 기능 개발, commit message는 상세하게 작성
• 개발이 완료되면 Pull request 생성 후 코드 리뷰 토의
• 리뷰가 끝나면 개발된 기능을 실제 서버나 테스트 환경에 배포
• 배포 도중에 문제 발생 시 기존 master를 다시 배포
• 테스트 종료 후 문제가 없으면 master에 merge하고 push 후 배포

 

 

어떤 전략을 사용할까?

 

맡은 프로젝트에 맞는 전략을 사용하자...

 

 

 

 

---

[git] Pull Request, Merge Request 차이

 

Gitlab 의 Merge Request, GitHub 의 Pull Request.

​

서로 기능은 동일하다.

내가 팀원으로서 MR, PR을 날렸을 경우

나의 작업내용(branch, fork)을 특정 브랜치(mater나 develop 등)에 끌어와서(pull)

병합(merge)해 달라고 요청(request) 하는 것이다.

​

예를 들어, 팀장(MR, PR을 받아주는 사람)이 MR, PR을 승낙할 경우

master나 develop 등 내가 내 소스를 병합하길 요청한 브랜치에 나의 작업물이 합쳐진다.