깃이란?
소스코드를 효과적으로 관리하기 위해 개발된
"분산형 버전 관리 시스템"이다.
Git에서는 소스 코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과
비교하거나 특정 시점으로 되돌아갈 수도 있다.
Git Repository(저장소)란 말 그대로 파일이나 폴더를 저장해 두는 곳이다. 그런데, Git 저장소가 제공하는 좋은 점 중 하나는 파일이 변경 이력 별로 구분되어 저장된다는 점이다. 비슷한 파일이라도 실제 내용 일부 문구가 서로 다르면 다른 파일로 인식하기 때문에 파일을 변경사항 별로 구분해 저장할 수 있다.
원격 저장소와 로컬 저장소
Git은 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공한다.
- 원격 저장소(Remote Repository) : 파일이 원격 저장소 전용 서버에서 관리되며, 여러 사람이 함께 공유하기 위한 저장소
- 로컬 저장소(Local Repository) : 내 PC에 파일이 저장되는 개인 전용 저장소
평소에는 내 PC의 로컬 저장소에서 작업하다가 작업한 내용을 공개하고 싶을 때에 원격 저장소에 업로드 한다. 물론 원격 저장소에서 다른 사람이 작업한 파일을 로컬 저장소로 가져올 수도 있다.
저장소 만들기
내 컴퓨터에 로컬 저장소를 만드는 방법은 두 가지가 있다.
1. 아예 저장소를 새로 만들기
2. 이미 만들어져 있는 원격 저장소를 로컬 저장소로 복사 해오기
변경을 기록하는 커밋(Commit)
파일 및 폴더의 추가/변경 사항을 저장소에 기록하려면 "Commit" 이란 버튼을 눌러줘야 한다.
Commit 버튼을 누르면 이전 커밋 상태부터 현재 상태까지의 변경 이력이 기록된 Commit(혹은 Revision)이 만들어 진다.
커밋은 시간순으로 저장되기 때문에, 최근 커밋부터 거슬러 올라가면
과거의 변경 이력과 내용을 알 수 있다.
(사진)
Tip
★ 버그 수정, 기능 추가 등 특별한 의미가 있는 업데이트를 작업 별로 구분해서 각각 커밋하면, 나중에 이력을 보고 특정 변경 내용을 찾기가 쉬워진다.
작업 트리(Work tree)와 인덱스(Index)
Git 에서는 우리가 흔히 말하는 폴더를 "작업 트리(Work tree)"라고 부릅니다.
그리고 커밋을 실행하기 전의 저장소와 작업 트리 사이에 존재하는 공간을 "인덱스(Index)" 라고 합니다.
정리
Git의 'Commit' 작업은 작업 트리에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라, 그 사이 공간인 '인덱스'에 파일 상태를 기록하게 되어 있습니다.
따라서 저장소에 변경 사항을 기록하기 위해서는, 기록하고자 하는 모든 변경 사항들이 '인덱스'에 존재해야 합니다.
푸시(Push)
웹 상의 원격 저장소로 변경된 파일을 업로드하는 것을 Git 에서는 푸시(Push) 라고 합니다. push를 실행하면, 원격 저장소에 내 변경 이력이 업로드되어, 원격 저장소와 로컬 저장소가 동일한 상태가 됩니다.
복제(Clone)
누군가의 변경 이력이 적용된 원격 저장소가 있으면, 그걸 웹에서 통째로 복제해와 내 PC에서 직접 작업할 수 있습니다.
원격 저장소를 복제하려면, 클론(Clone) 이라는 조작을 수행합니다.
복제란 원격 저장소의 내용을 통째로 다운로드하는 것을 말합니다. 복제한 저장소를 다른 PC에서 로컬 저장소로 사용할 수 있게 됩니다.
★ 변경 이력도 함께 로컬 저장소에 복제되어 오므로, 원래 원격 저장소와 똑같이 이력을 참조하고 커밋을 진행할 수 있습니다.
풀(Pull)
원격 저장소를 공유해 여러 사람이 함께 작업을 하면, 모두가 같은 원격 저장소에 푸시(Push) 합니다. 그럼 다른 사람이 원격 저장소에 올려놓은 Push 변경 내용을 내 로컬 저장소에도 적용할 필요가 있습니다.
원격 저장소에서 로컬 저장소로 업데이트 하려면 풀(Pull) 을 실행합니다.
Pull을 실행하면, 원격 저장소에서 최신 변경 이력을 다운로드하여 내 로컬 저장소에 그 내용을 적용합니다.
병합(Merge)
내가 끌어온 저장소가 최신 버전이 아닌 경우, 즉 내가 Pull을 실행한 후 다른 사람이 push를 하여 원격 저장소를 업데이트 해버린 경우에는 push 요청이 거부될 수 있습니다.
이런 경우에, 병합(Merge) 라는 작업을 진행하여 다른 사람의 업데이트 이력을 내 저장소에도 갱신해야 합니다. 만약, 병합하지 않는 채로 이력을 덮어쓰게 된다면 다른 사람이 push한 업데이트 내역이 사라져 버리기 때문입니다.
브랜치(Branch)란?
소프트웨어를 개발할 때에 개발자들은 동일한 소스코드를 함께 공유하고, 다루게 됩니다. 동일한 소스코드 위에서 어떤 개발자는 버그를 수정하기도 하고, 또 다른 개발자는 새로운 기능을 만들어 내기도 하죠, 이와 같이 여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없습니다.
이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 "브랜치(Branch)"입니다. 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경할 수 있습니다. 이렇게 분리된 작업 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있습니다.
브랜치(Branch) 란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.
또한 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge) 함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있습니다.
여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다.
이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이러한 방식으로 작업할 경우 '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.
Master 브랜치
저장소를 처음 만들면, Git은 바로 'master' 라는 이름의 브랜치를 만들어 둡니다, 이 새로운 저장소에 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(Commit) 하는 것은 모두 'master'라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다.
'master'가 아닌 또 다른 새로운 브랜치를 만들어 체크아웃(checkout) 하지 않는 이상, 모든 작업은 master 브랜치에서 이루어 집니다.
브랜치 전환하기(checkout)
위에서 말했듯이, 현재 선택된 브랜치가 아닌 다른 브랜치에서 작업을 하고 싶은 경우에는 '체크아웃(checkout)' 명령어를 실행하여 원하는 브랜치로 전환할 수 있습니다. 체크아웃을 실행하면, 우선 브랜치 안에 있는 마지막 커밋 내용이 work tree에 펼쳐집니다. 브랜치가 전환 되었으므로 이후에 실행한 커밋들은 전환한 브랜치에 추가됩니다
브랜치 통합하기(merge, rebase)
작업이 완료된 토픽 브랜치(Topic branch)는 통합 브랜치 (Integration Branch) 에 최종적으로 병합됩니다. 통합을 하는 방법에는 merge와 rebase 가 있는데, 어느 쪽을 사용하느냐에 따라서 통합 후의 브랜치의 이력이 크게 달라집니다.
merge
merge를 사용하면, 여러 개의 브랜치를 하나로 모을 수 있습니다.
