본글출처:http://slowalk.tistory.com/2470
혹시 git(깃)이라고 들어보셨나요? IT에 종사하거나 프로그래밍을 업으로 삼고 계신 분들은 알고 계실 텐데요. 오늘은 git을 처음 들어보신 분들이나, 써보려 했으나 진입장벽이 너무 높아 엄두가 안나셨던 분들을 위해 간략하게 git을 소개하고 활용하는 방법에 대해 알아보도록 하겠습니다(초보자 분들의 조금 더 쉬운 이해를 돕기 위해 git의 개념을 제 나름대로 재해석하였습니다).
git?
git은 분산 버전(이력)관리 시스템 입니다. 두 가지 기능이 합쳐져 있는데요. 바로 분산과 버전관리입니다. 자, 그럼 먼저 버전관리란 무엇일까요?
우리는 일상에서 알게 모르게 버전관리를 하고 있습니다. 간단한 예로, 학교 발표자료나 리포트를 작성한다고 했을 때, 여러분의 폴더 모습은 아마 아래와 같을 것입니다.
작성 중간중간 다른 이름으로 자주 저장해 두어야 정전과 같은 사태로 자료가 유실되는 불상사를 막을 수 있고, 잘못 수정된 자료가 있다면 과거 기록을 바탕으로 복원할 수 있겠죠? 위와 같이, 특정 시점을 기억하고 이를 재활용할 수 있게 규칙을 정해 파일을 관리하는 것을 버전(이력)관리라고 합니다.
그렇다면 분산은? 말그대로 내가 관리하는 문서를 여러 장소로 나누어 저장한다는 뜻입니다. git은 아래 그림과 같이 네트워크를 통해 연결된 다른 컴퓨터에 문서를 분산하여 관리할 수 있는 기능을 제공합니다.
문서를 분산하여 저장하면 어떤 장점이 있을까요? 만약 하나의 컴퓨터에서 문서를 저장/관리하는데 그 컴퓨터가 고장난다면, 해당 문서는 다시 볼 수 없게 될지도 모릅니다. 따라서 문서를 여러 장소에 나누어 보관한다면 위와 같은 상황이 발생해도 안전하게 문서를 복구할 수 있지요. 하지만 git의 분산 기능은 문서의 안정성만을 위한것이 아닙니다. git이 분산기능을 통해 구현하고자 하는 바는 바로 ‘협업’입니다.
예를 들어 1000페이지 분량의 논문이 있고, 이를 검수 및 수정하는 작업을 진행한다고 하겠습니다. 한 명이 하루에 검수 할 수 있는 양이 100페이지라 했을 때, 이 작업은 10일이 소요됩니다. 이를 5명이 나누어 진행한다면, 2일의 시간만이 소요될 겁니다.
또한, 5명 각자 동등하게 200페이지씩, 검수를 진행한다면 git을 쓰지 않아도 아무 문제가 없습니다. 다만 문서를 동등하게 분배하는 과정과 분배된 문서를 다시 하나의 문서로 합치는 불편함이 발생하겠네요! 그리고 동등한 200페이지라고 말은 하였지만, 작업의 양이 모두에게 공평하게 돌아가지 않았을 것입니다. 대부분의 문서는 처음과 끝부분에 목차와 색인 등이 있어서 분량이 적을 수도 있으니까요.
이렇듯 누군가는 조금 더 빠른 시간에 작업을 끝낼 수도 있고, 그 사람은 모든 작업이 끝날 때까지는 하나의 문서로 합치는 작업 또한 진행하지 못할 겁니다. 그 사람은 시간을 허투루 소모하고 있는 것이죠. 그렇다고 중간에 다른 사람이 작업하던 것을 다시 쪼개서 일을 하자니 그 비용이 더 들지도 모릅니다. 이렇듯 문서(작업)의 분배와 병합, 그리고 다른 사람의 작업 진행 정도를 파악하는 것이 협업의 가장 큰 걸림돌이라면 이를 손쉽게 만들어 주는 것이 git의 역할입니다!
git은 분산 기능을 통해 5명 모두가 하나의 문서를 동시에 편집할 수 있게 지원하고, 각자의 작업 내용을 기록으로 남겨 모두가 공유할 수 있습니다. 더 멋진 점은 동시 편집 중에 동일한 내용을 서로가 다르게 수정하였다면, 이를 자동으로 감지하여 `누구의 것으로 최종 병합할 것인가?`와 같은 기능을 제공하여 보다 손쉽게 협업을 진행할 수 있습니다.
git 기초 개념
git이 파일을 관리하는 단위는 “폴더(디렉토리)” 입니다. 특정 폴더를 저장소(repository)로 지정하면, 해당 폴더에 저장되는 파일과 하위 폴더들이 git이 관리하는 대상이 됩니다. 앞서 말씀드린 발표자료 예시처럼 하나의 파일만 이력관리를 하는 것이 아니라 여러 파일과 폴더를 묶어서 이력을 관리할 수 있습니다.
자 그럼 이제부터 git이 파일을 어떻게 추적하고 관리하는지 알아보도록 하겠습니다. git은 파일을 untracked, tracked, unstaged, staged 네 가지 상태로 관리합니다.
특정 폴더를 저장소(repository)로 지정하고 나면, 그 시점부터 해당 폴더에 생성(외부로부터 복사/이동 포함)되는 모든 파일들은 untracked 상태로 관리됩니다. untracked는 git이 “해당 파일은 이력관리 대상에서 제외된 파일이다.” 라고 생각하는 상태입니다. 따라서 untracked 상태의 파일 중, 이력관리를 하고싶은 파일이 있다면 git의 특정 명령어를 통해 tracked 상태로 변경해주어야 합니다(쉽게 말해, git에게 ‘앞으로 이 파일은 내가 이력을 관리할 파일이니까 변화를 잘 감시하고 있어!’ 라고 요청하는 것입니다).
이후, tracked로 변경된 파일은 staged 또는 unstaged의 상태만을 갖게 됩니다. tracked 상태의 파일이 수정이 되면 git은 이를 자동으로 감지하여 unstaged 상태로 변경시킵니다. unstaged 상태는 git이 해당 파일을 이력관리 대상으로 포함하고 있으나, 이력저장(commit) 행위를 할때는 제외되는 상태입니다. 이력저장(commit) 행위를 할때 저장되는 파일은 오직 staged 상태의 파일만 저장되는 점을 기억하시기 바랍니다.
다시 한 번 요약하자면,
앞서, git이 파일을 관리하는 네 가지 상태에 대해서만 말씀을 드렸는데요, 좀 더 중요한 개념이 있습니다. 바로 이력저장(commit)이라는 행위인데요. 이후 나오는 이력저장(commit) 행위에 대해서는 커밋 또는 commit이라고 통칭하겠습니다.
커밋을 설명하기 앞서, 혹시 나비효과 라는 영화를 아시나요? 그 영화에서 주인공은 자신이 쓴 일기를 통해 과거로 돌아갈 수 있습니다. 여기서 일기를 쓰는 행위가 바로 커밋입니다. git에서 커밋이란 그 당시 저장소의 폴더 및 파일 내용을 그대로 저장해 두는 행위이며, 당시 상황을 기억하기 위해 메모를 함께 기술합니다. 예를 들면 “A라는 파일에 B라는 내용을 추가했음”과 같이요. 그리고 나비효과 영화의 주인공 처럼 과거의 일기(커밋)를 보고 과거로 돌아갈 수 있습니다. 따라서 우리는 이러한 커밋을 통해 과거 시점으로 돌아가 삭제된 파일을 복구하거나, 과거로 부터 파일의 내용이 어떻게 변화되어 왔는지 추적 및 관리할 수 있습니다.
git 설치
그럼 이제부터 git을 본격적으로 사용하기 위해서 git을 설치해보도록 하겠습니다. git은 윈도우, 리눅스, 맥 등 대부분의 OS에서 설치하여 사용할 수 있게 개발되었지만, 이 글에서는 윈도우를 기준으로 설명 드리도록 하겠습니다.
윈도우에서 git을 사용하기 위한 다양한 프로그램이 존재합니다. 그 중 대표적인 것이 Git for Windows 입니다. 저는 이 프로그램을 사용하여 git을 설치해 보도록 하겠습니다.
먼저, 해당 사이트를 방문 하시어 프로그램을 다운받아 주세요. 다운로드가 완료되면 셋업파일을 더블클릭하여 설치를 진행합니다.저는 디폴트 옵션(무조건 Next)으로 설치를 진행하였습니다. 설치가 완료되면, 바탕화면이나 폴더 내에서 마우스 우클릭을 해봅니다.
[그림 1] Git 메뉴가 추가된 컨텍스트 메뉴
[그림 1]과 같이 컨텍스트 메뉴에 “Git GUI Here”와 “Git Bash Here”가 보이면 설치가 정상적으로 완료된 것입니다.
git 사용법
git을 사용하는 방법에는 두 가지가 있습니다. 바로 GUI 프로그램을 이용하거나 git 명령어를 이용하면 됩니다.
둘 중, 저는 git 명령어를 통해 사용법을 설명드릴 것입니다. 그 이유는 git GUI 프로그램은 다양한 이름으로 개발되어 있으며, 어떤 프로그램을 설치 하느냐에 따라서 사용법이 조금씩 다를 수 있기 때문입니다. 그리고 이런 GUI 프로그램들 또한 명령어를 기반으로 동작하기 때문에, git 명령어를 숙달하신다면 어떤 환경에서든 동일한 방법으로 git을 사용하실 수 있을 것입니다.
자, 그럼 지금부터 명령어를 통해 git의 사용법을 알아보도록 하겠습니다.
1. 저장소 생성
git을 사용하기 위해서 가장 먼저 선행되어야 하는 일은 저장소 생성하기 입니다.
git은 폴더(디렉토리) 단위로 저장소를 생성할 수 있습니다.
그럼, 지금부터 실습을 위해 애국가라는 저장소를 생성해보도록 하겠습니다.
첫번째로 내가 원하는 경로에 “애국가” 라는 폴더를 생성합니다.
그 다음, 해당 폴더를 마우스로 우클릭을 한 뒤, 표시되는 컨텍스트 메뉴에서 “Git Bash Here” 를 선택합니다.
[그림 2] 애국가 폴더로 이동 후, 마우스 우클릭 -> Git Bash Here
[그림 3] Git Bash Here CLI 명령어 창
마지막으로 [그림3]과 같은 CLI 창이 생성되었으면, 아래의 명령어를 입력합니다.
“Initialized empty Git repository in …” 과 같은 출력이 나오면 정상적으로 저장소가 생성된 것입니다. 윈도우 탐색기로 해당 폴더를 보면, 숨김폴더로 .git이라는 폴더가 생성되어 있는 것을 확인하실 수 있습니다.
[그림4] git 저장소가 생성된 애국가 폴더
2. 파일의 생성
생성된 저장소에는 일반 폴더와 마찬가지로 파일을 생성, 수정, 삭제할 수 있습니다.
하지만 일반 폴더와 저장소의 차이점은 무엇일까요?
바로 저장소내에 생성된 파일은 git이 관리해준다는 점입니다.
저장소에 파일이 처음 생성되었을 경우, git은 해당 파일을 untracked 상태로 관리합니다.
정말 그런지 확인해 볼까요? 그럼 애국가 저장소내에 “애국가1절.txt” 이라는 텍스트 파일을 생성해 보도록 하겠습니다.
[그림 5] 애국가 저장소에 생성된 애국가1절.txt 파일
파일이 생성되었다면 아래의 명령어로 파일의 상태를 조회할 수 있습니다.
[그림 6] git status 명령어로 확인해본 애국가1절.txt
예상대로 untracked 상태로 나오네요. 그럼 “애국가1절.txt” 파일을 git의 버전관리 대상(tracked 상태)으로 만들어 보겠습니다.
파일의 상태를 tracked 상태로 변경하고 싶다면, 아래의 명령어를 사용하면 됩니다.
git add [untracked 상태의 파일명] |
[그림 7] git add 명령어를 통한 파일 상태 변경
add 명령어를 통해 파일의 상태를 변경하였다면 status 명령어로 파일의 상태를 다시한번 확인해보시기 바랍니다. 아마도 [그림 7]과 같이 “애국가1절.txt” 파일이 초록색(tracked 상태)으로 변경되었을 겁니다.
3. 파일의 수정
이제 “애국가1절.txt”는 git의 이력관리 대상이 되었습니다. 그럼 이 상태에서 파일을 수정하면 어떻게 될까요? 현재는 아무 내용도 없는 “애국가1절.txt”파일에 애국가 1절 가사를 입력한 뒤 저장해 보겠습니다.
[그림 8] 애국가1절 추가 및 저장
status 명령어를 통해 상태를 살펴보니 unstaged 상태로 변경되었네요.
[그림 9] 파일 내용이 변경되어 unstaged 상태가 된 애국가1절.txt
4. 일기를 쓰자: 커밋
tracked 상태의 파일은 수정이 되면 git이 자동으로 감지하여 unstaged 상태로 변경시킵니다.
따라서 해당 파일은 커밋 대상에서 제외가 됩니다.
수정된 파일을 다시 커밋 대상으로 포함시키기 위해서는 앞서 untracked 파일을 tracked 파일로 변경시킬 때 사용하였던 add 명령어를 다시 사용하면 됩니다.
git add [unstaged 상태의 파일명] |
[그림 10] git add 명령어를 통하여 다시 staged 상태로 된 애국가1절.txt
지금까지 애국가를 1절을 작성하는 고된 작업이 끝나고나니 이 상태를 보관하고 싶어졌습니다.
앞서 나비효과 영화로 예로 들었던, 지금 이 순간을 일기로 남겨서 나중에 과거로 시간여행을 할 수 있게 말이죠!
커밋은 git이 현재 추적(tracked)하고 있는 파일중 staged 상태의 파일만 골라서 일기로 남기는 행위입니다.
자! 그럼 아래의 명령어를 통해 일기를 남겨 보시죠~
git commit -m ‘오늘의 일기~ 날씨 맑음
애국가 1절 작성 했음, 매우 힘들었음.’ |
커밋을 할때는 -m 옵션을 반드시 명시 하셔야 됩니다. 해당 옵션은 일기 내용이라고 생각하시면 되는데요. 일주일전 내가 뭘했는지 기억하실 수 있나요? 네, 저같은 평범한 사람들은 엊그제 먹은 점심도 기억 안 나기 마련이니까 과거를 되짚어 보기 위해서는 -m 옵션으로 로그를 반드시 기록해주셔야 합니다. 꼼꼼하고 자세하게 기록할 수록 기억이 좀더 명확해지겠죠?
이렇게 commit 명령으로 저장된 현재 상태는 커밋아이디가 부여되고 이를 통해 다른 커밋과 구분할 수 있는데요. 아래의 명령어를 통해 확인하실 수 있습니다.
[그림 11] git log 명령어로 커밋메세지와 commit id 확인
커밋아이디는 git이 중복되지 않게 생성 및 부여하므로 여러분은 신경 쓸 필요가 없습니다. 그리고 이 커밋아이디를 통해 우리는 과거로 돌아가는 마법을 부릴 수 있습니다.
5. 마법의 주문: 체크아웃
앞서 “애국가1절.txt” 문서를 생성하고 커밋을 했죠? 만약에 제가 전날 과음을 하여 실수로 어렵게 작성한 “애국가1절.txt”를 삭제하고 말았습니다. 그럼 다시 “애국가1절.txt”를 새로 작성해야 할까요? 아닙니다. 우리에게는 git이 있으니까요!
일단, 실험을 위해 저장소내의 “애국가1절.txt”를 삭제해 보도록 하겠습니다.
[그림 12] 사라진 애국가1절.txt
“애국가1절.txt” 파일이 사라지면 git은 어떻게 판단할까요? status 명령어로 확인해보겠습니다.
[그림 13] git status로 확인된 deleted 상태의 애국가1절.txt
[그림 13]과 같이 “애국가1절.txt”가 지워졌다고 하네요.
이 상태에서 “git add 애국가1절.txt” 명령어를 수행하고, commit을 하면 “애국가1절.txt” 파일이 사라진 상태를 커밋으로 남기게 됩니다.
해볼까요? “애국가1절.txt”가 사라진 시점을 커밋해 보도록 하겠습니다.
[그림 14] git add & commit 명령어를 통해 애국가1절.txt가 사라진 시점을 커밋
만약 앞으로도 “애국가1절.txt”가 필요없다고 하면 이상태를 유지하면서 작업하면 되겠죠? 하지만 실수로 인해 “애국가1절.txt”이 사라졌다고 가정하였으니 이를 복원해 보도록 하겠습니다.
“애국가1절.txt”를 복원하려면 과거로 돌아가야겠죠?
과거로 돌아가기 위해서 필요한 것은 checkout 명령어와 가고싶은 시점의 커밋아이디 입니다.
돌아가고 싶은 커밋 시점을 알기 위해서 git log 명령어를 통해 커밋아이디를 확인해보도록 하겠습니다.
[그림 15] git log 명령어로 조회해본 커밋 기록들
git log 명령어로 조회해본 결과 저희는 두건의 커밋 기록이 있네요.
“애국가1절.txt” 문서가 삭제된 커밋과 1절을 위키피디아에서 작성하여 저장한 시점의 커밋이 있습니다. 제가 돌아가고 싶은 시점은 문서가 생성되고 저장된, 커밋아이디 ebf484...가 되겠네요.
git checkout [커밋아이디] 명령어를 쓰실 때, 꼭 커밋아이디 전체를 입력하지 않아도 됩니다.
앞부분의 몇자리만 입력하여도 겹치는 아이디가 없으면 git이 알아서 판단하여 해당 시점으로 파일 상태를 되돌립니다.
[그림 16] git checkout 명령어로 커밋 시점 되돌리기
git의 커밋 시점이 변경되었습니다. 그럼 윈도우 탐색기로 해당 폴더를 다시 볼까요?
[그림 17] git checkout 명령어를 통해 과거 커밋 시점으로 돌아가 파일이 원복된 모습
checkout 명령어를 통해 과거 커밋 시점으로 되돌아가니 파일이 그대로 존재합니다!
하지만 이것은 임시로 과거 시점으로 돌아가 “애국가1절.txt”가 복원된 것이지 현재 작업하고 있는 시점으로 되돌아간다면 다시 사라지게 될 것입니다. 따라서 과거 시점으로 돌아가 되살리고 싶은 파일을 확인하였다면, 다음과 같은 명령어로 과거 커밋시점의 파일을 현재 작업 시점으로 되살릴 수 있습니다.
git checkout [커밋아이디] [파일명] |
위 명령어로 파일을 복원하기 앞서, 우리는 과거 커밋시점인 ebf484...에 있습니다.
그렇다면 과거 커밋으로 돌아가기 전인, 마지막 작업 시점으로 돌아가려면 어떻게 해야 할까요? 이때는 다음과 같은 명령어로 현재로 돌아갈 수 있습니다.
여기서 master는 git의 커밋아이디를 뜻하는 것은 아니고, 브랜치라는 개념인데요. 이 부분까지 설명드리자면 글의 분량이 너무너무 길어지기 때문에 다음에 자세히 다루도록 하겠습니다. 그냥 마지막으로 ‘작업하던 시점으로 돌아갈때는 git checkout master를 사용한다!’ 라고 기억해 두시기 바랍니다.
[그림 18] git checkout master 명령을 통해 마지막 작업 시점으로 복귀
마지막 작업 시점으로 돌아오고나니 받아들이고 싶지 않은 현실이 있습니다. “애국가1절.txt”가 다시 사라져 있습니다. 그렇다고 당황하지 마시고, 위에서 설명드린 git checkout <과거commit id> <복원하고픈 파일명> 으로 파일을 되살려 보겠습니다.
[그림 19] checkout <과거commit id> <복원하고픈 파일명> 명령어로 되살린 파일
위의 명령어를 수행하고 나니 “애국가1절.txt”가 복원되었습니다! git status 명령어로 파일 상태를 확인하니 unstaged네요. 그렇다면 git add 명령어로 파일을 staged 상태로 만든 뒤, 커밋한다면 지금 상태 또한 새로운 커밋으로 저장할 수 있겠습니다!
이렇듯, git은 파일의 백업 및 복구 뿐만아니라 과거 이력을 조회하고 재사용하는 등, 다양하게 활용될 수 있습니다.
마무리
지금까지 git에 대한 가장 기초적인 명령어와 개념에 대해 설명드렸는데요, 사실 git을 제대로 활용하려면 꽤 많이 공부해야 합니다. 이번 글에서 설명드린 git의 기능은 정말 빙산의 일각에 불과한 데요. 그만큼 제대로 공부하면 무궁무진하게 활용 가능한 것이 git입니다!
초기 진입장벽이 높아 초보자 분들께서는 사용할 엄두를 못내고 계신 분들도 많은데요. 이 글을 통해 조금이나마 장벽이 낮춰졌으면 하고, 조금 더 나아가 git에 대해서 호기심을 가지고 공부를 시작하셨으면 좋겠습니다!
