02_Git 버전관리

Git 버전관리

 

01. Git 버전 관리 개요

 

• Git은 세 개의 공간을 관리함
  • working directory(작업 공간)
  • stage(스테이지)
  • repository(저장소)
• 앞서 .git 폴더가 생성된 곳이 로컬 저장소
  • 프로젝트가 위치할 공간
  • 프로젝트가 위치할 공간을 작업 디렉토리 라고 함
• 깃은 작업 디렉토리 내에 위치한 파일 및 폴더의 현재 상태를 버전으로 만들고 버전을 관리
  • 즉, 작업 디렉토리는 버전 관리의 대상이 되는 공간
  • 작업 디렉토리 내에 새로운 파일 또는 폴더를 생성할 수도 있고, 수정하거나 삭제할 수도 있음(변경 사항을 만들 수 있음)
• 버전을 만든다 = 특정 순간의 변경 사항을 기억한다
  • 작업 디렉토리에 있는 프로젝트에 변경사항이 생기는 순간 새로운 버전을 만들 수 있음
  • 이 때 반드시 모든 변경 사항을 새로운 버전으로 만들 필요는 없음
    • 새로 만들 버전과는 크게 관련이 없거나 새로운 버전으로 만들만큼 중요하지 않거나, 임시로 변경했거나, 실수로 변경한 경우 등
  • 따라서 새로운 버전을 만들기 전에 작업 디렉토리에서 변경사항이 생긴 파일 중 다음 버전이 될 후보를 선별하는 작업이 필요
• 스테이지(stage): 변경 사항이 있는 파일 중 다음 버전이 될 후보가 올라가는 공간
  • 버전을 만들기 위해 작업 디렉토리에 있는 파일에 변경사항을 만들고
  • 이 변경사항 중 새로운 버전으로 만드려는 파일을 선별해 스테이지로 옮김
  • 스테이지는 스테이징 영역(staging area) 또는 인덱스(index)라고도 부름
  • 작업 디렉토리는 프로젝트가 위치한 공간이라 눈으로 볼 수 있지만, 스테이지는 명시적으로 보이지는 않음
• 스테이지에 있는 파일을 바탕으로 새로운 버전을 만들면 새 버전이 저장소에 추가
  • 저장소: 버전이 만들어지고 관리되는 공간
  • 저장소 또한 스테이지와 마찬가지로 사용자에게 명시적으로 보이지 않음
  • 스테이지에 올라온 파일을 토대로 새로운 버전을 만들면 새로운 버전이 될 후보가 더 존재하지 않기 때문에 스테이지는 비워짐
• 작업 디렉토리에서 버전이 될 후보 파일을 스테이지로 옮기는 것을 '스테이지에 추가한다(add)' 또는 '스테이지 시킨다(staged)' 라고 표현
• 스테이지에 추가된 파일을 '추가된(add) 파일' 또는 스테이지된(staged) 파일' 이라고 표현
• 저장소에 새로운 버전을 만드는 것을 '커밋한다(commit)' 라고 표현

 

 

02. 버전 관리

 

• 버전을 만들기 위해서는 로컬 저장소와 버전관리를 할 대상이 필요
• 커밋 메시지 작성
  • 스테이지에 올라온 파일을 새로운 버전으로 만드는 것은 커밋
  • 스테이지에 올라온 파일을 커밋한다면 새로운 버전이 만들어짐
  • 커밋 하기 전에 커밋 메시지를 작성해야함
    • 커밋 메시지: 버전을 설명하는 메시지
    • 내가 지금 어떤 파일을 어떻게 변경했는지 왜 이렇게 변경했는지 등의 내용을 담은 쪽지
    • 커밋 메시지는 크게 제목과 본문으로 이루어져 있으며 본문은 생략 가능
  • 커밋 메시지를 적지 않는다면 프로젝트 규모가 커지고 수많은 커밋이 쌓였을 때 다른 누군가가 누가, 언제, 어떤 변경 사항을 만들었는지, 이 변경 사항이 의미하는 것이 무엇인지 파악하기 어려움
    • 개발자에게 매우 중요한 의사소통 수단
    • https://bit.ly/3vBHKTy

 

03. .gitignore

 

• 버전에 포함하지 않을 파일이나 폴더를 자동으로 무시
• 작업 디렉토리 안에서 새로운 추가/수정/삭제가 이루어질 때마다 깃이 해당 변경사항을 알게됨
  • 깃으로 변경 사항을 추적하고 싶지 않은 파일이나 폴더가 있다면 .gitignore파일로 무시할 수 있음
    • .gitignore: 무시할 파일/폴더 목록을 적은 파일

 

04. 사용자에게 릴리즈

 

• 여러 커밋이 쌓여 있는 상황에서는 각각의 커밋을 구분할 수 있어야 함
• 각 커밋에는 고유한 커밋 해시가 있음
  • 각 커밋이 가진 고유한 ID
• 해시 값의 길이가 너무 길어서 해시 값의 앞부분 일부만 활용하는 경우도 있음
• 상위 항목 은 특정 커밋이 어떤 커밋에서부터 나온 것인지
  • 어떤 커밋을 변경해서 만들어진 커밋인지 표현

 

05. 태그 붙여 릴리즈

 

• 모든 의미 있는 소프트웨어는 사용자가 있음
• 웹 서비스를 개발한다면 충분히 기능을 개발하고 커밋을 쌓아나가 어느순간 사용자에게 결과물을 공개하게 됨
  • 개발한 소프트웨어를 사용자에게 공개하는 것을 릴리즈(release)라고 함
• 이 때 사용자에게 선보일 버전을 지칭할 때 커밋 해시를 사용한다면 가독성이 좋지 못함
  • 또한 개발자도 수많은 커밋 중 사용자에게 릴리즈한 유의미한 버전이 무엇인지 찾기 어려움
• 따라서 태그를 사용
  • 특정 커밋에 붙일 수 있는 꼬리표
  • 릴리즈되는 버전에 태그를 붙인다면 커밋이 여러 개 있는 상황에서도 의미 있는 커밋을 알아보기 쉬움

 

06. 버전 표기법

 

• 사용자에게 보이는 버전 표기 방식은 소프트웨어마다 다르고, 개발자가 정하기 나름
  • 연도.월.일
  • 숫자.숫자.숫자
  • 숫자.숫자
• 여기서는 가장 일반적인 버전 표기법을 소개
• vX.Y.Z
  • X : 주 버전(Major version)
    • 가장 중요한 버전
    • 일반적으로 새롭게 내놓은 버전이 기존에 내놓은 버전과 호환되지 않을 정도로 큰 변화가 있을 때 증가
  • Y : 부 버전(Minor version)
    • 일반적으로 새롭게 내놓은 버전이 기존에 내놓은 버전과 문제없이 호환되지만
    • 새로운 기능을 추가했을 때 증가
  • Z : 수 버전(Patch version)
    • 일반적으로 기존에 내놓은 버전과 문제이 호환됨
    • 버그를 수정한 정도의 작은 변화가 있을 때 증가

 

07. 작업 되돌리기

 

• 버전이 만들어지는 과정은
  1. 작업 디렉토리에서 변경 사항 생성
  2. 스테이지로 올리기
  3. 커밋
• 스테이지에 올라간 파일을 스테이지에서 내리기로 되돌릴 수 있음
• 스테이지에 올라가지 않은 파일 되돌리기를 하려면 폐기를 이용
  • 막 생성된 파일은 폐기 불가능
    • 새롭게 만들어진 파일의 변경 사항을 취소한다 = 파일이 만들어지기 전으로 돌아가겠다 = 파일을 제거
    • 따라서 방금 생성한 파일의 작업을 되돌리려면 제거를 클릭

 

08. 커밋 되돌리기

 

• 커밋한 내용을 되돌리는 방법은 크게 두가지가 있음
  • revert
    • 버전을 되돌리되, 되돌아간 상태에 대한 새로운 버전(커밋)을 만드는 방식
    • 기존의 버전은 삭제되지 않음
      • 예) 5버전에서 4버전으로 돌아가고 싶다면 4버전으로 돌아간 6버전이 만들어짐
  • reset
    • 되돌아갈 버전의 시점으로 완전하게 되돌아가는 방식
    • 되돌아갈 버전 이후의 버전은 삭제됨
    • reset은 크게 세 종류가 있음
      • soft reset
        • 작업 디렉토리 내 변경 사항과 스테이지에 추가된 변경 사항은 유지하되 커밋했다는 사실만 되돌리는 reset
      • mixed reset
        • 작업 디렉토리 내 변경 사항은 유지하되, 스테이지와 커밋을 되돌리는 reset
      • hard reset
        • 작업 디렉토리 내 변경사항까지 통째로 되돌리는 reset

 

09. 작업 임시 저장

 

• Git은 스태시(stash) 라는 임시 저장 기능을 지원함
  • 개발 과정에서 작업내역이 마음에는 들지 않지만 버릴 수는 없는 경우
  • 갑작스럽게 다른 일을 처리해야 하는 경우
• 스태시를 사용하면 작업 디렉토리에서 생성한 모든 변경사항이 임시 저장되고, 변경 사항이 생기기 전의 깨끗한 상태로 돌아감