문과생을 위한 Git - 02. What is Git?

2020/02/07 - [분류 전체보기] - 문과생을 위한 Git - 01. Why Git?

02. What is Git?

 

1. Git은 버전 관리 시스템이라는데?

2. Git만의 특징

3. Git의 주요 동작 프로세스

 

1. Git은 버전 관리 시스템이라는데?

앞에서 짧게 Git이 버전관리 시스템이라고 짧게 설명을 하였습니다.

버전관리 시스템은 기본적으로 우리가 어떤 작업을 했을 때, 그것의 최종본만 가지고 있는 것이 아니라 그 이전에 작업하여 저장했던 각 수정본을 모두 보유하면서 필요할 때마다 이전 버전을 참고하거나 되돌릴 수 있게 하는데 목적이 있습니다.

우리는 스스로 이미 많은 곳에서 버전 관리를 해오고 있었습니다. 무슨 말이냐고 한다면 우리의 작업물 이름 뒤에 날짜나 버전 명 등을 입력하면서 복수의 사본들을 만들어내는 일을 해온 것을 말합니다. 그래서 버전 관리는 도구라기보다는 일 또는 작업 그 자체라고 말하기도 합니다.

• 프로젝트명_날짜_버전1.doc

• 프로젝트명_날짜_버전2.doc

• ...

 

 버전 관리 시스템

위키피디아에서는 버전관리 또는 형상관리를 위해 사용하는 시스템을 다음과 같이 정의하고 있습니다.

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

 

---

 

2. Git만의 특징

Git을 잘 알기 위해서는 Git의 특징을 아는 것이 좋습니다.

2.1 로컬 저장소가 있다?

저장소 Repository

Git과 같은 버전 관리 시스템에선 저장소(Repository)에 각 버전 사본을 저장 또는 유지합니다.
저장소는 말 그대로 우리가 작업한 파일이나 폴더들을 저장하는 공간이라고 생각하면 됩니다.

 

다만 git과 같은 저장소에는 파일과 폴더뿐만 아니라 해당 파일과 폴더가 어떻게 변경되었는지
이력이 각 파일과 폴더별로 구분되어 저장된다는 것이 일반적인 저장소와 차이가 있을 뿐입니다.

 

그런데 git은 다른 것들과는 다르게 공동으로 작업한 결과를 저장하는 원격 저장소(Remote Repository) 이외에 그 중간에 Local Repository라는 개념이 있습니다.

 

Remote Repository

원격 저장소는 외부에 위치한 서버 형태로 관리되는 저장소로 여러 사람이 함께 파일이나 폴더를 공유하는 목적으로 만들어졌습니다.
버전 관리 시스템은 모두 원격 저장소에 공유 파일과 폴더를 저장하고 관리합니다.

 

Local Repository

내가 작업하는 공간(Working Directory)이 있고 작업 공간의 있는 것을 나의 개인 전용 PC 어딘가에 저장한다면
그곳이 바로 로컬 저장소(Local Repository)를 의미합니다.

 

클라우드를 사용하는 지금에는 원격 저장소에 대한 개념이 익숙하지만 로컬 저장소는 원격에 있는 곳과 대비되는
나의 개인 PC라고 생각하면 됩니다.

그리고 다른 버전 관리 시스템과는 다르게 git은 이 로컬 저장소가 있고 가장 두드러진 특징 중 하나입니다.

 

 

2.2 분산 협업이 가능하다?

Git에 대한 많은 소개 글 중에서 항상 분산 협업 에 대한 이야기가 있습니다.
일반적인 버전 관리 시스템에서는 하나의 작업 사본을 모든 사람이 공유하는 방식인데 반해
Git은 각자의 컴퓨터에서 자신만의 작업 사본을 가지고 작업을 하는 방식입니다.

 

완전한 새로운 공식 버전을 저장하기 전까지는 각자가 자신의 로컬 저장소에서 독립적으로 작업을 진행하고
이후에 소통을 거쳐 각자의 로컬 저장소에 있는 소스들을 병합하여 원격 저장소에서 공유하고 관리됩니다.

 

이때 병합 과정에서 동일한 소스의 부분이 다른 사람들이 서로 다르게 변경하여 병합하게 되면 충돌이 발생하게 되고
이러한 처리가 버전 관리 시스템에서는 유연하게 처리할 수 있도록 기능을 제공합니다.

 

그리고 분산 협업의 의미는 소스 들이 한 곳에만 저장되는 것이 아니라
프로젝트에 참가한 원격 저장소와 각 개인들의 로컬 저장소에 저장되어 있기 때문에
원격 저장소에서 문제가 생겨도 다른 로컬 저장소를 통해 복원이 가능한 장점이 있습니다.

 

분산 협업은 최근 블록체인을 통해 많이들 숙지하고 계신 개념이기도 합니다.

 

2.3 Staging Area가 있다?

Git은 Local Repository와 Remote Repository가 있다고 했습니다.

그런데 여기서 또 하나가 더 있습니다.

 

Staging Area라고 부르는 그것입니다. Git은 로컬 저장소에서 넘어가기 전에 변경사항들을 스냅샷 형태로 찍는 기능이 있습니다.

이 부분이 다른 버전 관리 시스템을 사용하시는 분들에게 가장 크게 생소하여 이해하고 사용하는데 걸림돌이 되는 부분이기도 합니다.

 

Staging Area에 들어갔다(staged)는 작업을 하면서 내용이 변경된 파일이나 폴더가 수정이 되었다는 것(modified)과는 다릅니다.

수정된(modified) 파일과 폴더의 내용 중에서 어떤 부분의 변경사항을 저장소에 저장할 지, 반영할 지를 선택하는 것에 가깝습니다.

 

이러한 과정이 번거로울 수 있지만 저장소에 반영할 때 중간 과정이 추가되면서 더 안전하게 변경 사항을 반영할 수도 있고 자유롭게 할 수 있습니다.

선택된 사항들은 staged 상태이고 commit을 통해서 변경사항들을 저장하게 됩니다.

 

앞에서 이야기한 로컬 저장소와 commit의 개념때문에 Git은 다른 버전 관리 시스템과는 달리
사용자 개별적으로 어떤 순간(스냅샷)에 대한 변경 이록에 대한 history들을 확인할 수 있습니다.

이는 SVN 같은 중앙집중형 버전 관리 시스템과 같이 변경된 내용이 중앙 저장소로 저장되어 버전의 history가 다른 사람들 모두에게 적용되면서 자신만의 개별 history를 가질 수 없는 것과 크게 대비됩니다.

 

2.4 Branch가 유연하다

브랜치(Branch)는 '나뭇가지', '지점', '분점'이라는 뜻을 가진 단어입니다.
버전관리에서 나뭇가지가 왜 필요하지? 라는 생각이 들게 됩니다.

 

작업을 하다보면 기존 작업에서 파생되지만 조금은 독립적인 작업을 따로 해야 하는 때가 있습니다.

네XX에 쉽게 로그인하는 프로그램이 기존 근간이 되는 작업물이 있는데 이 작업물을 이용해 뉴스를 수집하는 프로그램을 개발하고 싶다고 합시다. 이런 경우에는 기존의 네이버에 로그인하는 부분에서 새로운 브랜치를 만들어(나뭇가지를 뻗어) 기존의 나무 기둥에서 벗어나서 작업을 하게 됩니다.

 

하지만, 나뭇가지는 한 번 뻗어나가 생성되면 다시 다른 나뭇가지와 합쳐지지 않지만(?) Git의 Branch는 나뭇가지들끼리 자유롭게 합쳐지고 다시 나눠집니다. 그래서 Branch를 나뭇가지보다는 냇물로 비유한 표현이 가장 적합한 게 아닌가 다른 블로그를 보에서 그러한 표현을 보면서 무릎을 치며 생각했습니다.

 

냇물(Stream)은 물의 흐름을 의미하는데 냇물을 생각해보면 기본 큰 물줄기가 있고 그 물줄기에서 다른 물줄기로 빠져나갔다가
다시 어떤 물줄기가 돼서 원래의 기본 큰 물줄기에 합류하기도 하고 다시 뻗어나가기도 하는 것들을 생각해보실 수 있습니다.

개발도 이와 많이 비슷하고 branch도 이와 비슷한 속성을 보입니다.

 

 

 

Git은 기본적인 branch를 master 라고 표현 합니다. master는 운영을 위한 소스흐름으로 그리고 별도의 dev branch를 만들어 운영에 지장을 주지 않도록 개발 서버에서 테스트가 가능한 독립된 branch를 구성할 수 있습니다. dev에서 작업한 내용은 그 완결성이 보장되면 master에 반영되는 식으로 branch 운용 전략을 세울 수도 있을 것입니다.

 

dev에서는 뭔가 기존 흐름에서 새로운 무언가를 도입하고자 실험을 해볼 수 있는데 기존의 흐름에는 영향을 주고 싶지는 않을 때 새로운 branch를 만들어 볼 수 있을 것입니다. 새로운 branch에서의 실험이 성공적이라면 기존 branch의 새로운 branch를 병합(merge)하면 됩니다. 만약 실험이 실패했다면 새로운 branch는 삭제하거나 그대로 두게 되는데 기존 흐름에 영향을 주지 않는 별도 공간에서의 작업이기 때문에 문제가 되지 않습니다.

 

 

 

---

 

3. Git 사용 전 웜업

3.1 기본 동작 프로세스

 

git clone vs. git pull

git clone은 다운로드의 개념과 가까워서 어떤 저장소의 파일을 다운로드하는 것을 의미

git pull은 clone과 유사하게 원격 저장소로부터 한번에 working directory까지 파일이 변경된다는 점에서 비슷해 보이지만 pull은 기본적으로 원격 저장소와 연결이 된 상태이고 브랜치의 변화를 반영하여 작업을 하기 위한 것이다는 점에서 큰 차이가 있음

 

주요 명령어

• git init
  깃 저장소를 초기화한다. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 그냥 일반 폴더이다. 이것을 입력한 후에야 추가적인 깃 명령어들을 줄 수 있다.
• git config
  “configure”의 준말, 처음에 깃을 설정할 때 가장 유용하다.
• git help
  명령어를 잊어버렸다? 커맨드 라인에 이걸 타이핑하면 21개의 가장 많이 사용하는 깃 명령어들이 나타난다. 좀 더 자세하게 “git help init”이나 다른 용어를 타이핑하여 특정 깃 명령어를 사용하고 설정하는 법을 이해할 수도 있다.
• git status
  저장소 상태를 체크. 어떤 화일이 저장소 안에 있는지, 커밋이 필요한 변경사항이 있는지, 현재 저장소의 어떤 브랜치에서 작업하고 있는지 등을 볼 수 있다.
• git add
  이 명령이 저장소에 새 화일들을 추가하진 않는다. 대신, 깃이 새 화일들을 지켜보게 한다. 화일을 추가하면, 깃의 저장소 “스냅샷”에 포함된다.
• git commit
  깃의 가장 중요한 명령어. 어떤 변경사항이라도 만든 후, 저장소의 “스냅샷”을 찍기 위해 이것을 입력한다. 보통 “git commit -m “Message hear.” 형식으로 사용한다. -m은 명령어의 그 다음 부분을 메시지로 읽어야 한다는 것을 말한다.
• git branch
  여러 협업자와 작업하고 자신만의 변경을 원한다? 이 명령어는 새로운 브랜치를 만들고, 자신만의 변경사항과 화일 추가 등의 커밋 타임라인을 만든다. 당신의 제목이 명령어 다음에 온다. 새 브랜치를 “cats”로 부르고 싶으면, git branch cats를 타이핑한다.
• git checkout
  글자 그대로, 현재 위치하고 있지 않은 저장소를 “체크아웃”할 수 있다. 이것은 체크하길 원하는 저장소로 옮겨가게 해주는 탐색 명령이다. master 브랜치를 들여다 보고 싶으면, git checkout master를 사용할 수 있고, git checkout cats로 또 다른 브랜치를 들여다 볼 수 있다.
• git merge
  브랜치에서 작업을 끝내고, 모든 협업자가 볼 수 있는 master 브랜치로 병합할 수 있다. git merge cats는 “cats” 브랜치에서 만든 모든 변경사항을 master로 추가한다.
• git push
  로컬 컴퓨터에서 작업하고 당신의 커밋을 깃허브에서 온라인으로도 볼 수 있기를 원한다면, 이 명령어로 깃허브에 변경사항을 “push”한다.
• git pull
  로컬 컴퓨터에서 작업할 때, 작업하고 있는 저장소의 최신 버전을 원하면, 이 명령어로 깃허브로부터 변경사항을 다운로드한다(“pull”).