[Git] Git의 기본 개념과 용어 정리

 조별 과제를 모두 해본 적이 있을 것이다. 조별 과제를 하다 보면, 발표 자료 PPT나 발표 대본 스크립트 등을 여러 사람이역할 분담하여 작성하면서 최종으로 사용하게 될 자료가 계속 바뀌게 되는데, 이때 어떤 게 가장 최신 버전인지 헷갈린 경험이 분명 있을 것이다!

 프로그래밍 코드도 마찬가지다. 프로그래밍 코드는 특히나 이런 발표 자료보다 더더욱 많은 프로젝트 참여자, 각 참여자가 수정하는 사항들이 더더욱 많이 생기게 마련이다. 이번 포스팅에서는 프로그래밍에서 형상관리에 엄청난 도움을 주는 'Git'이라는 툴에 대해 알아보도록 하자!

문서 관리의 중요성 / 출처 : https://backlog.com/git-tutorial/kr/intro/intro1_1.html

---

1. 'Git'을 왜 써야 할까?

  1-1. Git 의 정의

  : 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템.

 

  1-2. *형상 관리를 하는 이유

  * 형상 관리 : 소프트웨어 구성 관리(Software Configuration Management) 또는 형상 관리는 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다.

 

다음 그림을 살펴보자. 사람 A,B,C,D가 나눠서 협업하여 진행하는 프로젝트 'X'가 있다고 가정해보자.

 

협업 프로젝트 'X' / 출처 : cupjoo.tistory.com/6

협업하는 프로그래밍 프로젝트를 경험해봤다면 다음과 같은 문제가 충분히 발생할 수 있다는 걸 분명 알 것이다!

• A가 맡은 기능을 다 구현했는데, B가 맡은 파트를 아직 완성하지 못해서 B의 완성된 코드를 공유받지 못해 다음 단계로 나갈 수가 없는 상황
• B가 코드를 완성하고 A의 코드와 합쳤으나, 코드 충돌이 발생하여 심각한 에러가 발생, 애플리케이션이 정상 작동하지 않는 상황. 이로 인해, C와 D는 A와 B의 코드가 완성되어야 진행할 수 있기 때문에 하염없이 기다리는 상황이다.
• A와 B의 코드가 완성되어(Code 1) 이제 C가 Code 1에 본인의 기능을 추가한 Code 2를 코딩하고 있는데, 심각한 에러가 발생하여, Code 2의 처음 상황(Code 1)으로 돌아가야 하나, 백업해 둔 사람이 아무도 없는 상황
• 어찌저찌하여 Code 2까지 완성했고, D가 Code 2에 이은 Code 3 을 작성하는 중에, 호환성 문제를 발견하여 Code 1 부분에서 수정이 필요한 상황인데, 어느 부분에서 수정을 해야 하는 지 알 수 없는 상황

위 상황 하나하나가 모두 협업 프로젝트를 진행해봤다면 알겠지만, 잘못하면 시간만 어마어마하게 잡아먹을 수 있는 아찔한 상황이다. 이러한 상황을 방지하기 위해 협업 프로젝트에서의 형상 관리는 필수이다.

 

Git은 이러한 형상 관리를 매우 편리하게 도와주는 Tool로서, 분산 버전 관리를 통해 작업 일지 기록이나 협업, 백업 등을 가능하게 해준다. 또한 형상 관리 Tool 들 중 현재로선 점유율이 가장 높은 관계로, 개발자를 하기로 마음 먹었다면 git에 대해 반드시 알아야 한다!

---

2. Git 의 개념과 용어 정리

Git의 단순한 구조 / 출처 : cupjoo.tistory.com/6

위 그림을 보면, Git의 구조를 대충 파악할 수 있다. 요약하면 이렇다. 최종 소스코드를 저장하고 공유하는 역할인 원격 저장소가 있고, 여기에서 소스코드를 내 로컬 저장소(내 PC)로 받아와서 소스코드를 수정한 후, 다시 원격 저장소로 업로드하는 구조이다. 그럼 이제 Git에서 실제 사용하는 용어를 중심으로 Git이 어떤 기능을 가지고 있는지 살펴보자!

 

2.1. Git의 저장소의 종류

● Remote Repository (원격 저장소)

: 원격 서버(GitHub)에 저장된 저장소로, 여러 사람이 함께 공유한다.

 

●  Local Repository (로컬 저장소)

: 사용자가 직접 관리하는 저장소로, 내 PC 에 저장되어 있다.

 

2.2. 프로젝트의 전체 복사

clone 과 fork의 구분

● Clone

: Remote Repository 에서 내 Local Repository로 복사하여 내 PC에 새로운 저장소를 만드는 것.

- Clone 한 원본 Repository(Remote) 를 origin 으로 갖고 있는데, 기본적으로 이 origin에 대한 권한이 없으면, 해당 저장소로 push 할 수 없다. 

- Clone을 하게 되면, 내 PC의 지정된 폴더에 .git 이라는 숨겨진 폴더가 생성되고, 이러한 .git 폴더를 가지고 있는 폴더를 '작업 폴더(Working Directory)' 라고 한다. 이 작업 폴더는 자동으로 github의 Remote Repository와 링크가 맺어지게 된다.

 

● fork

: 다른 사람의 Remote Repository(Github) 에서 내 Remote Repository(Github)으로 복제하는 기능.

- 원본(다른 사람의 Remote Repo)과 연결되어 있으며, 여기서 '연결되어 있다'의 의미는, Original Repository에 어떤 변화가 생기면, forked 된 Repository로 Fetch나 Rebase의 기능을 통해 변동사항을 반영할 수 있다. 

- 원본(다른 사람의 Remote Repo)에 내가 수정한 코드를 적용하고 싶으면, 해당 저장소에 PR(Pull Request)를 해야 한다.

이때, 원본의 관리자로부터 승인을 받으면, 내가 수정한 코드가 Commit&Merge 되어, 원본 Repo (다른 사람의 Remote Repo)에 반영된다. 

 

2.3. 내 로컬 Repo 에서의 변경 사항 관리

Stage의 개념 / 출처 : cupjoo.tistory.com/6

※ Stage(Staging)

: 특정 파일이나 코드를 변경한 후 해당 이력을 *Index 에 기록하는 행위.

 

*Index : commit 을 통해 변경사항들이 반영되기 전, 해당 변경 사항의 이력들이 저장되는 '공간'을 말한다. Staging Area 라고도 한다. commit 되기 이전의 임시 저장소라고 생각하면 된다. 

 

● Add

: 작업 폴더(Working Directory) 는 처음에는 아직 관리 대상(Tracked)이 아니다. Untracked 인 상태는 아무런 히스토리 정보를 가지지 못하는데, 우리가 Git을 사용하는 목적은 이러한 히스토리를 관리하기 위함이다. 따라서 해당 작업 폴더를 관리 대상으로 삼기 위해, add 명령어를 수행해주어야 한다. 처음 add 명령을 수행하면, Index 가 생기고, 이후 모든 수정 사항에 대한 Staging 행위(add 명령을 통해 수행)가 Index 에 저장된다. 

 

● Commit

: Staging 된 파일들을 Local Repository에 등록하는 행위. 스냅샷의 형태로 Local Repository에 저장되며, 하나의 commit 단위로 해당 파일을 롤백할 수도 있고, 미래(?) (더 이후 시점의 commit)로 갈 수도 있다.

 

2.4. Local Repository -> Remote Repository 변경사항 반영하기

● Push

: 현재 내 로컬 저장소에서 작업한 변경 사항들을 원격 저장소에 반영하는 것을 말한다.

- 로컬 저장소의 commit 된 모든 내용 그대로 원격 저장소에 올린다.

- 대부분 commit 직후에 수행하여 원격 저장소에 곧바로 변경사항을 적용시킬 때 사용하며, push가 완료되면, 로컬 저장소와 원격 저장소의 소스코드 내용이 동일하게 된다.

 

● Merge

: 두 개 이상의 개발 히스토리(branch) 를 하나로 합치는 작업을 의미한다.

- merge를 하게 되면, 각각의 개발자가 작업한 히스토리가 모두 보존(Preserved) 된다는 특징이 있다.

 

● Rebase

: branch 의 base 를 재설정하여 다시 커밋을 재적용하는 작업을 의미한다.

Git Rebase 개념

Git Rebase 예시 / 출처 : devowen.com/430

- git rebase master feature-2 는 feature-2 브랜치를 master 브랜치로 리베이스 한다는 의미로, master 브랜치의 가장 최근 commit 뒤로 feature-2 브랜치의 commit들이 붙게 된다. 이때 엄밀히 말하면, feature-2의 commit들은 rebase 되면서, 아예 다른 commit이 되는 것이므로, C5*, C6* 로 표기하는 것이 맞다.

- 각 branch들은 해당 branch의 최초 히스토리가 되는 base 지점을 가지고 있는데, 이러한 base 지점을 새로운 브랜치로 갱신하여, 히스토리를 하나로 통합하기 위해 사용한다.

- Rebase 는 충돌을 유발할 수 있어, 아래의 원칙을 지키는 것이 바람직하다.

• 원격 저장소에 올라간 커밋은 리베이스 하지 말 것.
• rebase 전에 rebase 하려는 브랜치 끝에서 백업 브랜치를 만들어 놓을 것.
• 큰 규모의 팀에서는 되도록 merge를 할 것.

 

2.5. Remote Repository -> Local Repository 로 변경사항 가져오기

● Pull

: 원격 저장소에 있는 변경사항들을 로컬 저장소로 가져와 소스코드를 병합(Merge)하는 명령어.

- Fetch + Merge 의 개념으로 보면 된다.

- 일단 한 번은 원격 저장소와 링크가 맺어져 있어야(Clone 또는 Fork 이후) 실행 가능한 명령어이다.

 

● Fetch

:  원격 저장소에 있는 변경 사항들을 로컬 저장소에 병합하기 전, 해당 변경 내용들을 확인만 하려고 할 때 사용하는 명령어.

- 로컬 저장소로 변경된 소스코드 내용을 가져오지는 않음 (코드 합치려면 Merge가 필요함.)

- 원격 저장소의 최신 commit 이력을 로컬 저장소의 이름 없는 브랜치로서 가져오게 된다. 이 브랜치는 'FETCH_HEAD'의 이름으로 Checkout 도 가능하다.

---

참고

https://cupjoo.tistory.com/6

Git에 대해 알아보자 1. Git의 개념과 Git Flow

https://ux.stories.pe.kr/182

그림으로 보는 Git의 개념 이해하기

https://wlqmffl0102.github.io/posts/Git-organizing-the-terms/

Git 용어 정리

 

https://backlog.com/git-tutorial/kr/intro/intro1_1.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog