Git과 GitHub

임지원·2024년 4월 26일

Git이란?

버전 관리 시스템 (Version Control System, VCS)의 하나로 버전을 관리할 수 있는 수단이다.

버전 관리 시스템

파일의 변화를 시간의 흐름에 따라 기록하고 이후에 필요한 상황에서 필요한 파일을 가져올 수 있는 시스템이다. 또한 작성자도 기록이 되기에 누가 언제 문제를 일으켰는지 파악하기 쉽다.

예시)
'과제1'을 덮어쓰기 한 경우 처음의 '과제1'을 불러올 수 없지만,
'과제1_0405', '과제1_0407', '과제1_0409'와 같이 파일을 버전별로 따로 저장하면 필요한 버전을 꺼내 쓸 수 있다.

Git을 사용하는 이유

Git은 VCS중 분산 버전 관리 시스템(Distirbuted VCS)이다.

DVCS는 파일의 마지막 snapshot을 사용하지 않고 저장소를 히스토리를 포함하여 모두 복제하기 때문에 서버에 문제가 생겨도 복제를 통해 다시 복원할 수 있다.

이 방식을 사용하면 복구가 쉽고, 서버의 문제가 있어도 로컬의 데이터로 작업할 수 있으며, 원격 저장소에 올리기 전이면 다른 개발자에게 영향 없이 수정 할 수 있다.

Git과 GitHub

git과 github는 뗄 수 없는 관계이다.
두 개념이 헷갈리기 때문에 정리가 필요하다.

Git

  • 로컬에서 관리되는 버전 관리 시스템
  • 직접 코드를 수정하며 버전 관리
  • 코드를 관리하는 형상 관리 도구

GitHub

  • 깃을 사용하는 프로젝트를 지원하는 웹 기반 호스팅 서비스
  • 클라우드를 통해 관리되는 버전 관리 시스템
  • 깃과는 다르게 자체 구축이 아닌 클라우드를 빌려쓰는 개념이다.

즉 GitHub는 Git이라는 소프트웨어를 클라우드로 운영되는 웹 서비스이다.

Git의 주요 개념

  1. Repository(저장소)

    • 코드들이 저장 되어 있는 물리적인 공간
  2. Working Tree

    • 흔히 사용하는 '폴더'를 의미한다.
  3. Index(Staging Area)

    • Commit을 실행하기 전의 저장소와 Working Tree 사이에 존재하는 공간
      Working Tree > Index > Commit의 순서이다.
  4. Commit

    • 작업 과정의 점검이 끝난 후 저장소에 남기는 과정
  5. Checkout

    • 특정 시점이나 branch의 소스 코드로 이동하는 행위
  6. Branch

    • Commit 단위로 구분된 소스 코드 타임라인에서 분기되어
      새로운 commit을 쌓을 수 있는 가지
  7. Merge

    • Branch와 Branch를 합치는 작업, 즉 병합 과정이다.

Git의 주요 명령어

  • git init : Git 저장소를 만드는 명령어 .git폴더가 생성된다.

  • git status : 깃 저장소의 상태를 확인한다.

  • git add : 커밋에 파일의 변경 사항을 포함하도록 한다.

  • git commit : "git commit -m '저장명'" 등과 같은 명령어로 주로 사용한다. 이 명령어를 통해 커밋을 생성하고, 변경 사항을 확정하여 반영한다.

  • git clone : 원격 저장소의 저장소를 로컬에서 이용할 수 있도록 복사해 가져온다.

  • git log : 현재 커밋 목록들을 확인 가능하다.

  • git checkout : 현재 버전에서 이전 버전의 커밋으로 이동하거나 변경 전의 브랜치로 접근 가능하다.

  • git push : 소스 코드의 변경 사항을 원격 저장소에 반영한다.

  • git pull : 원격 저장소의 변경 내용이 현재 디렉토리로 가져와진 뒤, (fetch) 병합된다.

  • git merge : 브랜치들을 병합한다. 작업 마무리 단계에서 시행한다.

Git-Flow와 GitHub-Flow

Git-Flow


장점

  • 브랜치별로 책임을 명확히 하는 규칙성
  • 매우 디테일하게 버전 정보 제공
  • master에 있는 코드는 매우 깔끔한 상태 유지(테스트되고 최종 수정된 것만 반영되기 때문)
  • 브랜치별로 역할이 있으므로 문제가 있더라도 문제 발생시 각 브랜치를 대기 시킬 필요가 없음(freeze)

단점

  • 많은 브랜치 때문에 생기는 복잡한 규칙
  • release 로 인한 많은 동기화 작업
  • 애자일의 반복적인 접근법과 Git-Flow의 엄격하고 구체적인 규칙과 충돌

GitHub-Flow


장점

  • 깔끔하고 간단한 협력 규칙
  • 지속적인 통합과 개발의 편리함
  • 빠른 피드백과 이슈 발행 및 변화를 독려
  • feature 개발 이후 dvelop, release까지 전달할 필요가 없음

단점

  • Git-Flow에 비해 체계적이지 않음. 자유분방한 코드 관리로
  • 전체적인 개발 프로세스 관리가 더 힘들어질 수 있음
  • 짧은 주기가 아닌 큰 주기의 release의 환경에는 맞지 않음
  • 운영과 개발 브랜치 모두를 감당하는 master 브랜치는 코드가 지저분 할 수 있음
  • release 준비와 버그 수정이 모두 master 브랜치에 있으므로 특별한 주의가 더 필요함

전략 선택 법

작은 조직이나 개발의 볼륨이 작다면 빠르고 간소화된 파이프라인을 갖고 있는 GitHub-Flow

체계적이고 관리의 책임이 명확해야하는 프로젝트 Git-Flow

profile
백엔드 새싹

0개의 댓글