Git

Git 개념, 원리

Aburger 2024. 4. 29. 17:49

0. 개요

분산형 버전 관리 시스템(Version Control System)의 한 종류로서, 빠른 수행 속도에 중점들 두어 개발된 툴이다.

이전의 중앙집중식 버전 관리 시스템(Centralized VCS)들이 주로 사용되었으나, 깃(Distributed VCS)의 등장으로 인해 네트워크 의존성이 감소하며 작업 유연성이 늘어나고, 로컬 작업으로 돌아가기에 속도가 빨라지며 개발자들에게 유연성과 효율성을 제공한다.

0-1. 버전관리

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

  • 각 파일을 이전 상태로 되돌릴 수 있다(복원).
  • 프로젝트를 통째로 이전 상태로 되돌릴 수 있다.
  • 시간에 따라 수정 내용을 비교해 볼 수 있다.
  • 누가 언제 이슈를 만들었는지 추적할 수 있다.
  • 파일을 잃어버리거나 잘못 수정했을 때에도 쉽게 복구할 수 있다.

1. Git

1-1. Git의 필요성

모두 같은 환경에서 개발하여 불필요한 시간을 없애주고 서로 코드를 주고 받는 과정에서 일어나는 충돌을 최소화 시켜준다.

프레임워크를 갖추고 공통으로 쓰는 코드들을 미리 넣어두고, 테스트코드나 샘플코드들을 넣어주면서 프로젝트 개발 시작하기 전에 팀원 코두 같은 코드로 테스트 할 수 있는 환경도 제공할 수 있다.

 

  1. 갑과 을이 같은 웹사이트에서 동시에 같은 'A'페이지를 업데이트 중이라고 가정한다.
  2. 갑은 무언가를 변경하고 저장한 다음 'A'페이지를 업로드 한다.
  3. 을의 'A'페이지 작업도중 문제가 발생한다.
  4. 만약 확인하지 않고 동시에 작업을 한다면 누군가의 작업은 겹쳐 쓰여질 것이고 지워질 수 있다.
  5. Git은 이와 같은 일을 사전에 방지한다.
  6. 갑과 을은 같은 페이지에 각자 수정사항을 업로드 할 수 있고, 두개의 복사본을 저장한다.

1-2. Git의 장점

  • 소스 코드를 주고 받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능하다.
    • 브랜치(branch)를 통해 개발한 뒤, 본 프로그램에 합치는 Merge방식으로 개발을 진행할 수도 있다.
  • 분산 버전 관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있고, 중앙 저장소가 날라가버려도 원상복구할 수 있다.
  • 팀 프로젝트가 아닌 개인 프로젝트일지라도 Git을 통해 버전 관리를 하면 체계적인 개발 및 프로그램이나 패치를 배포하는 과정도 간단해진다.

1-3. Git의 작동 방식

Git을 운영하는 방법은 여러가지가 있다.

가장 대표적인 원격저장소의 파일을 로컬 저장소에 다운로드 받아서 작업 후 다시 업로드 하는 방식을 기준으로 하여 순서를 살펴보자.

 

1. git clone

원격 저장소에서 Clone하는 것과 그냥 다운로드 하는 것은 다르다.

  1. Download ZIP: 순수하게 파일들만 압축해서 다운로드 한다.
  2. Clone with HTTPS: Clone은 순수 파일들과 프로젝트에 커밋되었던 히스토리 정보까지 모두 다운로드가 되어 로컬저장소(Local Repository)를 만들어 준다.
$ git clone <저장소 url>

서버에서 파일을 Clone하게 되면 내 컴퓨터에 지정된 폴더에 .git이라는 숨겨진 폴더가 생성되며, 이 .git을 가지고 있는 폴더가 작업 폴더(Working Directory)가 된다. 이 작업 폴더는 자동으로 서버와 링크가 맺어진다.

 

1-1. 작업 폴더(Working Directory) 구성

작업폴더는 관리(추적)가 되는 파일과 관리(추적)가 되지 않는 파일로 나누어져 있다.

관리(추적)가 된다는 것은 이 파일의 생성, 수정, 삭제 등의 히스토리 정보를 모두 가지고 있다는 뜻이다.

 

파일 관리(추적) 상태

추적은 바로 이전의 커밋을 기점으로 아래 4가지 상태로 관리한다.

  • 추적 안함(Untracked): 관리 대상이 아님
  • 추적 함(Tracked)
    • 수정 없음(Unmodified): 변경이 없는 파일
    • 수정 함(Modified): 변경된 파일
    • 스테이지 됨(Staged): 스테이지에 올라간 파일

 

2. git add

작업 폴더에 처음 파일을 생성한다면 이것은 아직 관리(추적)대상이 아니다.

관리 대상이 아닐 경우는 아무런 히스토리 정보를 가지고 있지 않다.

이 파일을 관리 대상으로 삼기 위해서는 git add명령어를 실행해 주어야 한다.

git add명령어를 실행하면 이 파일이 스테이지(Staging Area)로 올라가게 된다.

이제부터 이 파일의 수정, 삭제 등의 모든 정보는 Git에 기록되게 된다.

$ git add <파일 이름> // 특정 파일만 추가하기
$ git add . // 모든 파일을 추가하기

파일의 상태는 추적안함(Untracked), 수정함(Modified)이 스테이지 됨(Staged)으로 변경된다.

 

 

3. git commit

이제 스테이징 된 파일들을 로컬 저장소(Local Repository)로 등록을 해야 한다. 그러기 위해서는 git commit을 해야 하는데, git commit은 현재 스테이징된 파일들을 그대로 스냅샷 찍어서 로컬 저장소(Local Repository)에 보관하게 된다.

이 스냅샷이 하나의 히스토리 기록이다.

이 기록을 기준으로 과거로 되돌아 갈 수도 있고 미래로 갈 수 있으며 다른 브랜치로 이동할 수 있는 기준점이 된다.

$ git commit -m "참고할 설명 작성"

파일의 상태는 스테이지 됨(Staged)이 수정없음(Unmodified)으로 변경된다.

 

 

4. git push

git commit으로 로컬 저장소(Local Repository)에 스냅샷을 찍어 이용하는 것은 내 컴퓨터에서만 가능한 상태이다.

이것을 서버에 올려서 다른 사람들과 공유를 하기 위해서는 원격 저장소(Remote Repostiory)에 업로드를 해야 한다.

git push명령어를 사용하면 로컬 저장소의 커밋(git commit)의 모든 내용이 그대로 원격 저장소로 올라가게 된다.

 

 

5. git pull

원격 저장소에 올라온 최신 수정본 파일을 내 로컬 저장소로 업데이트를 해야 할 때가 있다.

그럴때 명령어 git pull을 사용한다. 일단 한번은 서버와 링크가 맺어져 있어야 한다.

또는 git fetch명령어를 사용할 수 있다.

 

git fetch는 원격 저장소의 최신 변경사항을 로컬 저장소로 가져온다.

가져온 변경사항을 자동으로 합치지 않고, 가져온 변경사항을 로컬에서 확인하거나 병합, 리베이스 등의 추가작업이 필요하다.

git pull은 git fetch를 수행한 후에 자동으로 로컬 브랜치에 병합된다.

일반적으로 간단한 작업을 할 때는 git pull을 사용하는 것이 편리하다.

자동으로 로컬 브랜치로 병합하기에 작업 흐름을 더욱 단순화할 수 있다. 특히나 협업 과정에서는 원격 저장소의 변경 사항을 자주 가져오고 병합하기 때문에 git pull을 자주 사용한다.

 

하지만 프로젝트나 작업의 복잡도가 높아지면 git fetch와 함께 로컬 작업과의 조율이 필요할 수 있다.

2. Git 기본 용어

  • Repository
    • 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳.
    • Git은 원격 저장소(Remote Repository)와 로컬 저장소(Local Repository) 두 종류의 저장소를 제공한다.
      • 원격 저장소 Remote Repository
        • 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소다.
      • 로컬 저장소 Local Repository
        • PC에 파일이 저장되는 개인 저장소다.
        • 저장소를 만드는 방법은 두가지가 있다. 새로운 저장소를 만들거나, 이미 만들어져 있는 원격 저장소를 로컬 저장소로 복사(Clone)해올 수 있다.
          스테이지 내용은 .git/index파일에 저장되고 저장소의 내용은 .git/HEAD 파일에 저장된다.
  • Working Tree, Working Directory
    • 저장소의 한 시점. 개발자가 작업하는 시점(Tree).
    • 파일 수정, 저장 등의 작업을 하는 디렉토리로 '작업 디렉토리(working directory)'라고도 한다.
  • SnapShot
    • 특정 시점에서 파일, 폴더 혹은 워크 스페이스의 상태를 의미.
    • 스냅샷을 통해 특정 시점에 어떤 파일에 어떤 내용이 기록되어 있었는지, 폴더 구조는 어떠했는지, 어떤 파일이 존재했는지 등 저장소의 모든 정보를 확인할 수 있다.
    • Git에서는 새로운 버전을 기록하기 위한 명령어인 커밋(commit)을 실행하면 스냅샷이 저장된다.
      • 1. 개발자는 작업 디렉토리에 있는 파일을 수정.
      • 2. 수정된 파일을 모아 정리하려 만든 Snapshot을 Staging 디렉토리에 추가 후 저장.
      • 3. GIT디렉토리에 저장(Staging 디렉토리에 저장된 파일을 앞으로 영구 불변의 상태를 유지하는 Snapshot 으로서 git 디렉토리에 저장)
  • Checkout
    • 이전 버전 작업을 불러오는 것.
  • Staging Area
    • 저장소에 커밋하기 전에 커밋을 준비하는 위치.
    • 예로 workingTree에서 10개의 파일을 수정했는데 4개의 파일만 버전으로 만드려면 4개의 파일만 스테이지로 넘겨주면 된다.
    • 즉, 로컬 스테이지에 올려둔 파일만 원격 저장소에 커밋할 자격이 있다.
  • Commit
    • 현재 변경된 작업 상태를 점검을 마치면 확정하고 로컬 저장소에 저장하는 작업.
      • push는 로컬 저장소의 변경사항을 원격 저장소에 업로드 하는 작업.
  • Head
    • 현재 작업중인 Branch를 가르킨다.
  • Branch
    • 가지, 분기점을 의미.
    • 작업을 할 때 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 판단되면 Merge를 하여 작업.
  • Merge
    • 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업.

3. Github vs GitLab

깃 허브는 세계 최대 규모의 Git 저장소로 무료 저장소를 지원하여 초급~고급 개발자들 모두 이용하는 서비스이다.

무료로 이용하는 대신 자신의 소스코드가 오픈되어 수많은 사람들이 보며 활용 가능하고, 익명의 개발자와 함께 작업할 수 있도록 하여 프로그래밍을 더욱 확산 시켜주는 환경으로 자리하고 있다.

 

반면 GitLab은 수많은 기업에서 보안성을 중시하는 프로그램 코드를 올려 협업하는 툴로 애용한다.

사용자는 대부분 기업이며, 자신의 서버에 설치하여 서버 내 private한 Git Remote Repository를 만들 수 있는 서비스이다.

반응형
저작자표시 (새창열림)