오픈소스계의 영원한 아이돌 리누스 토르발스는 리눅스 커널을 관리하는 기존 툴이 엉망인 것에 너무 빡친 바람에 Git이라는 소스관리 툴을 만든다. 리누스는 하도 빡친 나머지, 단 2주만에 완성하는 기염을 토했다.
이 또한 리누스의 은혜겠지요...
우리에겐 Linux OS의 창시자로 잘 알려진 Linus Torvalds(이하 리누스)에게는 사실 Linux의 개발 말고도 많은 업적이 있다. Git의 개발은 리누스의 업적 중 Linux의 개발 말고 가장 잘 알려져 있는 그의 업적이면서, 동시에 가장 자주 쓰이는 소프트웨어이다.
리누스는 Git을 최대한 1. 빠르고 2. 빠르고 3. 빠르게 만드는 것에 주력했는데, 이는 Git이 무려 Linux의 개발을 위해 제작되었기 때문이다. 그 커다란 Linux Kernel 코드의 변경 사항을 추적하려면, 기존의 상용 소프트웨어로는 어림도 없었고, 이에 리누스가 2주만에 Git의 초기 버전을 제작했다는 비화가 전해져 온다.
현재의 Git은 속도뿐만 아니라 뛰어난 분산 저장소의 특징과, GitHub 서비스의 제공으로 훨씬 다양하고 폭넓은 분야에서 쓰이고 있고, 이런 Git은 컴퓨터 공학도로서 당연히 알아야 할 기본 소양 수준까지 오게 되었다.
- Git의 기본적인 구조
Git은 기본적으로 다음과 같은 구조를 갖는다.
- 원격 저장소(Git Server 안의 Remote repository)가 존재하고
- 내 PC(Local PC)에서 원격 저장소에 접근해서
- 저장소를 Clone(Local PC 안의 Cloned repository)하고
- Commit/Push/Pull 등을 진행한다.
이해를 돕기 위해 Git 없이 발표 자료를 관리하는 한 예시를 들어보겠다.
예를 들어, 발표 자료를 준비한다고 생각해보자. 이 발표 자료는 또한 각 수정 버전을 보관할 필요가 있다고 가정한다.
보통 발표 자료를 처음 제작하기 시작하면, 내 컴퓨터에서 작업이 이루어진다. 그 뒤 적당한 초기 버전이 완성이 되면, 그 발표 자료를 v1로 표시하고 클라우드 시스템에 업로드한다. 내 컴퓨터에서는 계속 작업을 진행하고, 오늘 할 분량이 마무리되면 해당 버전의 이름을 표시해 클라우드에 v2로 업로드 한다.
다음 날 아침, 학교에 가는 버스에서 노트북을 열고 클라우드에 저장된 v2를 다운로드 받아 수정하고, 버스에서 내리기 직전 v3라는 이름으로 클라우드에 다시 업로드한다. 일과를 마치고 집에 와 내 컴퓨터에서 클라우드에 저장된 v3를 다운로드 받아 수정하고, 해당 내용을 v4로 업로드 한다.
Bare repository(혹은 위의 그림에서는 Remote repository)란 간단하게 말해서 핵심 저장소이다. Bare repository는 위 예시에서 사용된 클라우드 서비스와 같은 역할을 한다.
Cloned repository는 위 예시에서 각 컴퓨터와 노트북에 다운로드 된 파일들을 말한다. 저장소는 여러 컴퓨터에 복제되어 동시에 존재할 수 있으며, 또한 작업물은 어디서든지 업로드가 가능하다.
이제 위 예시에서 문제점을 찾아보자. 잘 알고 있겠지만, 이러한 시스템은 몇가지 치명적인 약점이 있다.
- 각 버전 간의 논리적인 연결이 존재하지 않는다. 즉 버전 이름을 제외하고는 v1 다음으로 저장된 시스템이 v2인지 v1.1인지 확실히 알 수가 없다.
- 각 버전의 수정 내용과 무관하게, 버전을 업로드 할수록 용량을 크게 잡아먹는다.
- 두 개 이상의 복제본이 동시에 새 버전으로 업로드 될 때 충돌을 피할 수 없다.
Git은 이러한 문제를 해결하기 위한 최고의 도구이며, 이에 대해서는 진행하며 차차 알게 될 것이다.
먼저 GitHub와 같은 복잡한 시스템에 대해서 학습하기 전에, 지금은 우선 내 PC 안에서만 Git을 한 번 운용해보자.
이하 실험 환경은 Linux(Ubuntu)에 기반하고 있으며, Windows에서 하고 싶으면 달라진 커맨드는 직접 조사 해야한다. 다운로드를 제외하면 Windows에서도 모든 커맨드는 거의 유사하다.
기본적으로 Git은 아까 위의 그림처럼 서로 떨어진 컴퓨터 간의 커뮤니케이션이 가능한 시스템이지만, 당연하게도 내 컴퓨터 안에서 두 시스템을 모두 구축해서 Git을 사용하는 것도 가능하다.
- 네트워크를 거치지 않고, 내 컴퓨터 안에 두 시스템이 같이 들어있는 구조
Git의 이해를 위해 우선은 내 컴퓨터 하나만을 가지고, 지지고 볶고 해보자.
우선은 Git을 다운로드 한다. 다음과 같은 명령어를 통해 간단하게 Git을 다운로드 받을 수 있다.
sudo apt-get install git # Git 다운로드, 윈도우는 웹에서 직접 다운로드본 문서에서는 Linux의 기본적인 명령어에 대해 부연설명하지 않을 예정이니 궁금하다면 검색을 해보길 바란다. (# Special 0 코스로 간단한 Shell 사용법을 추가하였다. 참고)
이제 우리의 Bare repository를 만들어 보자. 아까도 말했듯이 원격 저장소이지만 지금은 그냥 내 컴퓨터 안에 만들거다.
mkdir ~/test-repo # test-repo 폴더 생성
cd ~/test-repo # test-repo로 이동
git init --bare # test-repo를 Git 원격 저장소로 만들기위와 같은 과정을 거치면 해당 test-repo 경로 안에 뭔가 이상한 내용물이 잔뜩 생길 것이다. Git에 대해 진지하게 심도있는 학습을 하고 싶은 것이 아니라 단순히 Git의 사용법만을 익힐 생각이라면, 각 파일에 대해서 깊이있게 알 필요는 없다.
어쨋든 방금 만들어진 + 초기화된 저 test-repo가 바로 우리의 원격(사실 아님) 저장소이다. git init --bare는 현재 위치한 폴더를 원격 저장소로 만드는 명령으로, 자주 쓰이지는 않지만 알아두어야 하는 내용이다.
이제 원격 저장소를 Clone(이하 클론)해서 내용을 수정하고, 업로드 해볼 차례이다. 복제된 저장소의 이름은 기본적으로 원격 저장소의 이름과 같기 때문에 충돌이 발생할 우려가 있으므로, 다른 경로로 이동해서 작업을 진행한다.
mkdir ~/cloned # cloned 폴더를 별도로 생성
cd ~/cloned # cloned 폴더로 이동
git clone ../test-repo # 아까 만든 test-repo를 클론내 홈 폴더 내에 cloned이라는 하위 폴더를 만들고, 그 안에서 아까 만든 원격 저장소를 복제했다. git clone [PATH]는 [PATH]에 있는 원격 저장소의 내용을 현재 경로 아래에 복제한다.
이제 파일을 추가할 차례다. 복제된 저장소에 파일을 만들어보자. 간단하게 Hello, Git!이라는 문구를 가진 텍스트 파일을 추가한다.
cd ~/cloned/test-repo # 클론된 복제 저장소로 이동
echo "Hello, Git!" > hello.txt # 복제 저장소에 파일 추가 및 내용 작성이제 해당 복제 저장소는 복제 당시와 비교했을 때 변경사항(hello.txt 추가)이 생겼고, 이 변경사항을 원격 저장소에 업로드하여 버전을 관리하게 되는 것이다.
Git에 변경사항을 업로드하기 위해서는 우선 업로드 할 파일의 목록을 추가해야 한다. 이는 add 명령으로 이루어지며, 다음과 같이 사용한다.
git add hello.txt # 변경사항 등록이제 변경사항 중 hello.txt의 추가가 업로드 할 리스트에 등록 되었다고 생각하면 된다. 물론 모든 파일에 대해 이렇게 추가할 필요는 없다. git add .을 사용하면 현재 폴더에 속한 모든 파일과 하위 폴더, 그 안의 파일들 까지 모든 변경사항의 업로드를 준비한다.
주의할 점은 git add .을 사용하는 현재 경로를 기준으로 하기 때문에, 정확히 모든 파일을 업로드하려면 현재 경로에 따라 . 대신 Git 최상위 경로를 적절히 넣어야 할 것이다. (만약 현재 위치가 한 폴더 아래라면 ..을 대신 사용할 수 있다)
Git에는 현재 편집자가 누구인지 알려주어야 하는 특징이 있다. 간단히 아래와 같이 설정을 완료하자.
git config --global user.email [YOUR_EMAIL@example.com] # 유저 이메일 설정
git config --global user.name [YOUR_NAME] # 유저 이름 설정--global Flag는 해당 설정을 이 저장소에 대해서만 적용할 건지, 아니면 전역적으로(OS 유저 단위) 설정할 것인지를 정하는 Flag로 특별한 이유가 없다면 --global로 하자.
추가만 한다고 끝이 아니다. 이제 변경사항을 Commit(이하 커밋) 해야한다. 커밋은 변경사항의 리스트들을 묶어 메시지와 함께 한 버전으로서 기록을 남기는 과정을 말한다.
git commit -m "feat: start to learn git" # 등록된 변경사항들을 묶어서 커밋간단히 commit 키워드와 메시지 플래그 -m [MSG]을 사용해서 [MSG]와 함께 변경사항을 기록한다. 이때 메시지는 해당 변경사항을 간단히 나타내는 정도면 충분하며, 보통 일반적인 규칙은 인터넷을 찾으면 잘 나와있다.
이 커밋 메시지라는 것은 반드시 포함되어야 하며, 그 이유는 훗날 메시지에 "." 만 찍어서 커밋을 10번 정도 연속으로 했다가 이전 버전을 돌아봐야하는 일이 생기면 알게된다.
커밋을 마치면 내 복제 저장소와 원격 저장소가 서로 다른 최신 버전을 기억하게 될 것이다. 이렇게 서로 다른 버전을 서로간에 맞추는 방법은 바로 Pull/Push(이하 풀/푸시)이다.
그 중 풀은 원격 저장소의 버전이 앞서있을 때 그 앞선 버전을 내 복제 저장소로 끌고 오는 것이고, 푸시는 내가 수정한 내용을 원격 저장소로 업로드 하는 것이다.
만약 두개 이상의 복제 저장소에서 하나의 원격 저장소 버전에 대해 서로 다른 새 버전을 만들고 푸시를 시도한다면 어떻게 될까? 첫번째 푸시는 문제가 없겠지만 두번째 푸시는 충돌이 발생할 가능성이 존재한다. 이에 대한 해답은 후에 다시 이야기 해보도록 하자.
지금은 원격 저장소에서 버전을 끌어와서 수정하고, 그 내용을 다시 원격 저장소로 업로드하는 과정이므로 둘 중 푸시가 맞다. 따라서 푸시를 진행하려면 다음과 같이 진행한다.
git push # 원격 저장소로 현재 커밋을 푸시오류 메시지가 발생하지 않았다면 정상적으로 푸시가 이루어진 것이다. 그렇다면 이제 제대로 업로드 되었는지 확인해 보자. Git 저장소의 정보는 복제 저장소 내에 숨겨진 폴더로 존재하는 .git이라는 경로 내에 있다. 즉, 해당 폴더만 건재하다면, 언제든 변경사항을 원격 저장소와 주고받을 수 있다는 이야기이기도 하다.
이번에는 우리의 복제 저장소를 지워버린 다음, 다시 클론을 사용하여 우리가 방금 푸시한 버전으로 복구해보자.
cd ~/cloned # 다시 cloned로 이동
rm -rf ./test-repo # 아까 복제해두었던 test-repo를 삭제위 커맨드를 실행하면 복제 저장소가 사라진다. 이제 다시 원격 저장소에서 버전을 불러와보자.
git clone ../test-repo # 원격 저장소에서 다시 복제
cd ./test-repo # 다시 복제한 test-repo로 이동
ls . # 현재 폴더의 내용 확인
cat ./hello.txt # hello.txt의 내용 확인그리고 다시 한번 원격 저장소에서 업로드 된 버전을 불러오게 되는데, 아까 마지막으로 업로드한 내용 그대로 다시 클론된 것을 알 수 있다.
마지막으로 풀 명령은 git pull로 간단히 사용 가능하며 풀을 사용하여 원격 저장소의 최신 버전이 복제 저장소보다 앞서있다면, 해당 내용을 끌어와 최신 버전으로 업데이트 할 수 있다.
이제 여태까지 배운 내용을 토대로 아래의 미션을 수행해보자.
- Git 원격 저장소를 내 컴퓨터에 만들고
- 해당 저장소를 두 위치에 클론한 뒤
- 한쪽 복제 저장소에서 파일을 추가한 뒤 해당 버전을 업로드하고
- 다른쪽 저장소에서 그 파일이 추가된 버전을 내려 받아보자
- Test alone