지옥에서 올라온 GIT 리뷰

이민기·2024년 4월 5일

DevOps

목록 보기

2/4

개요

제대로 된 프로젝트 진행을 앞서 스터디를 진행했다. 이번 주 스터디는 GIT이었고 나는 생활코딩의 ‘지옥에서 올라온 GIT’을 바탕으로 기존에 몰랐던 내용을 정리하였다.

기본적인 명령어는 알고 있는 상태로 학습 하였다. 주로 몰랐던 내용은 GIT의 내부 구조, Branch 병합, 실제 활용 등이었고 이를 위주로 정리하였다. 명령어 정리는 인터넷에 매우 많고 이번에 강의를 들으면서 느낀 점은 GIT이 용도나 구조적으로 매우 잘 만들어졌는데, 생각보다 단순하다. 사용할 때 구조와 원인을 모르면 어렵겠지만 아래 ‘git help’를 쳤을 때 나오는 command가 전부이고, 자주 쓰는 command들이 또 나뉜다.

새로 깨달은 내용

“git add는 단순히 추가가 아닌 제외 시킬 파일을 배제하기 위해 명확하게 git에게 알려주는 용도이다.”
“버전과 변화는 다르다. 버전은 의미 있는 변화가 있어야 한다. 어떠한 작업이 있을 때 작업의 완결된 단위가 존재한다. 하지만 버전의 의미와 범위는 정해져 있지 않다.”
“하나의 commit 1개의 작업을 담고 있는 것이 이상적이다.”
“우리가 add를 사용하는 이유 중 하나는, 우리는 commit을 잊을 때도 있다. 하나의 단위로 commit을 못했을 때 나누어서 commit하기 위해서”
“reset 작업은 버전을 (인터넷에)공유했을 때 하면 절대 안된다. reset 작업은 본인의 PC에 있는 작업에 한에서만 실행해야 한다.”
“git은 웬만하면 어떠한 정보를 지우지 않는다. 단지 눈에 보이지 않는 것이다.”

GIT의 구조

Blob(Binary Large Object)은 Commit의 이름이다. 이때 저장되는 해시 값(1e038be4d13c~)은 파일 콘텐츠를 바탕으로 만들어졌다. 즉 내용을 주소로 사용한다.

Git은 데이터를 저장하기 전에 항상 체크섬을 구하고 그 기준으로 데이터를 관리합니다. 그 체크섬을 구하는데 SHA-1 해시를 사용하고, 그러면 체크섬은 160 bit가 되고, 이를 16진수로 표현하면 40자가 됩니다. 이 40자는, 온 세상에서 “거의” 유일한 값이 나오므로, 고유키로 쓸 수 있습니다. 그리고 찾고자 하는 범위를 “한 저장소 안”으로 좁히면, 앞의 몇 글자만 써도 대부분 달리 겹치지 않아서, 여덟 자나 열 자로만 줄여서 쓸 수도 있습니다.

git add를 하면 index에 추가된 Blob값을 볼 수 있고 해쉬 값을 비교하여 tree로 만들 준비를 한다.
git commit을 하면 위에 구조에서 봤던 것 처럼 기존의 commit은 parent가 되고 Blob들은 Tree로 묶여서 저장이 된다. 또한 구조상 탐색이 쉽고 내용의 변화를 찾기위해서는 Hash값, 즉 파일에 대한 ID만 비교하면 되기 때문에 버전 관리에 유용하다.

GIT Reset

Working Directory : 내가 작업을 하고 있는 git에 올리려는 Directory

Index : git add를 했을 때 해쉬로 저장된 Blob들

Repository : git commit을 하여 local 저장소에 저장된 변경 내용

우리가 코드가 꼬이거나 뒤로 돌아갈 때 Reset을 쓰게 되는데 Reset은 3가지 종류가 존재하며, 되돌리는 범위가 다르다. (reset 명령어를 할 때 —soft, —mixed, —hard를 붙이지 않으면,—mixed로 동작한다.)

GIT-Merge

Conflict가 없을 때

git에서 merge를 할 때는 수정&병합시키고 싶은 branch로 이동하고 merge를 진행시킨다. 이때 좋은 점은 같은 파일이어도 수정한 위치가 다르면 자동으로 합쳐준다.

Conflict가 있을 때

만약 수정한 위치가 서로 같은 경우에는 Conflict가 일어난다.
그리고 Branch Conflict를 알려주면 Conflict가 일어난 파일의 위치를 알려준다.

Merge Tool

merge를 사용하기 위한 tool들이 존재한다.
해당 예제에서는 kdiff3를 사용했다.

충돌이 일어난 2개의 파일과 공통 조상의 파일을 가져온다.

충돌을 쉽게 수정할 수 있다.

2way-merge : 2개를 비교하며 동일하지 않을 경우에 Conflict 혹은 auto merge가 이루어짐
3way-merge : 2개의 commit을 merge하기 위해서 2개의 commit의 기본이 되는 조상 commit을 Base로 3개의 commit을 비교한다.

Git Rebase

merge의 방법 중 하나로 Rebase라고 한다. 말 그대로 이해하면 쉽다. Base(토대)를 바꿔준다.
위의 예시에서는 하나의 branch를 다른 branch의 Base(토대)로 만들어주고, 1개의 branch만 남기어서 원래부터 1개의 branch였던 것처럼 보여주고 실질적으로는 Base(토대)만 바꾸어 주었다.
참고 : rebase는 다른 사람이 사용하지 않은 commit에 대해서 진행하라고 하였다.

여기서 master는 로컬 저장소 우리가 git만 이용했을 때, origin/master는 우리가 remote로 연결한 origin이라는 위치의 master이다. 즉 origin/master는 원격 저장소(ex github)의 master를 뜻한다.

Git - Pull VS Fetch

원격 저장소의 값을 가져올 때 2가지 방법이 있다. pull과 fetch이다.
보통은 pull을 사용

git pull을 사용하면 원격 저장소가 가르키고 있는 commit의 위치(origin/master)로 로컬 저장소(master)가 이동한다.

git fetch를 사용하면 해당 원격 저장소의 commit은 가져오지만 현재 내 로컬 저장소는 변경이 없다. 만약 여기서 commit 7과 다른 내용의 commit 8을 push하면 master와 origin/master는 commit 8을 가르킬 것이다.

Git - Fork VS Clone

fork는 다른 사람의 레포지토리를 가져와 변경 가능하게 하는 것이다. 우리가 사용하는 git clone과 같아 보이지만 git clone은 fork한 원격 저장소를 연결해서 데이터를 복사하는 작업이

Git Tag

release할때 version을 tag에 추가해준다. annotated tag는 commit처럼 message를 넣을 수 있다.

Git Flow

git flow는 깃에서 제공하는 강력한 브랜칭 기능을 활용한 변경이력 관리 전략이다.

feature branch : 기능을 개발하는 branch
develop branch : 기능을 합치며 release branch의 오류와 추가파일 등이 merge되는 branch
release brabch : develop branch에서 release할 때 테스트로 인한 오류 수정과 추가 파일들을 넣는 branch로 commit할 때마다 develop branch와 merge를 시켜주어야 한다.
hotfix branch : master branch의 오류를 신속히 수정할 때 사용하는 branch이다.
master branch : release하기 위한 프로그램의 branch이다.