10. Git의 저장 방식과 GitHub의 공유 역할 구분하기
0. 학습 목표
→ 사본 저장의 불편을 직접 확인하고 Git과 GitHub의 역할을 구분합니다.
0.1 이번 글에서 다룰 내용
0.1.1. 문제점 확인
[학습 단위 1]에서 만든 노트는 실습 PC 한 대에만 저장되어 있습니다. 이 상태에서는 세 가지 문제가 생깁니다.
- 노트가 수정되면 이력이 남지 않아서, 지난 문서 내용을 되살릴 방법이 없습니다. (어제 지운 문장)
- 노트가 PC 한 곳에만 있어서, PC가 고장 나면 노트 전체를 잃어버리고,
- 다른 사람과 협업할 방법도 없습니다.
0.1.2. 해결책 살펴보기
개발 현장에서는 이 세 가지 문제를 Git과 GitHub이라는 두 도구로 해결합니다.
- Git은 [1] 내 컴퓨터에 설치해서 사용하는 프로그램이고,
- GitHub은 [2] 인터넷을 통해 이용하는 서비스입니다.
0.1.3. 최종 목표
복잡한 소프트웨어 개발에 Git과 GitHub 를 사용하기 전에,
이 과정에서는 Obsidian 학습 노트라는 간단한 프로그램을 연습 대상으로 Git, GitHub에서 자주 쓰는 기능 일부에만 먼저 익숙해지는 것을 목표로 합니다.
① 사본 파일로 저장하는 방식에서 불편 확인하기
→ ② Git이 저장 시점을 기록으로 남기는 방식 확인하기
→ ③ GitHub이 저장소를 인터넷에 보관하는 방식 확인하기
→ ④ 내 학습 기록을 공개할 때 지울 내용 판단하기
Obsidian 노트에서 익힌 Git과 GitHub 사용법을 나중에 소스코드를 관리로 자연스럽게 이어가시면 됩니다.
💡 핵심: Git은 내 컴퓨터에서 저장 시점을 기록하는 프로그램이고, GitHub은 그 저장소를 인터넷에 보관하고 공유하는 서비스입니다.
0.2 이번 강의 실습 내용
오늘은 설치도 실습도 하지 않습니다.
다음 네 가지를 우선 살펴봅니다.
- 문서의 기본 저장 방식은 "덮어쓰기" 입니다.
그렇기 때문에 문서는 추가로 사본을 만드는 불편한 방법을 사용합니다. - Git 이 사본 파일을 만들지 않고 저장 시점의 기록한다는 점을 대조해 구분합니다.
- GitHub 에 내 컴퓨터의 Git 저장 폴더를 인터넷에 보관하고 공유합니다.
그리고 Git과 GitHub 두 도구를 1)비교하며 2)역할을 이해합니다.
이 구분이 되어 있어야 12강에서 저장소를 만들고 13강에서 GitHub에 올릴 때 지금 어느 도구를 다루는지 알 수 있습니다.
준비물은 웹 브라우저만 있으면 됩니다. GitHub 계정은 오늘 필요하지 않습니다. 계정 만들기와 플러그인 설치는 11강에서 합니다.
1. 문서 저장과 불러오기 방식의 문제점
→ 지금 쓸 수 있는 유일한 방법인 사본 저장을 직접 해 보고 불편을 확인합니다.
1.1 사본 파일 만들고 원본 수정하기
문서의 기본 저장 방식은 "덮어쓰기" 입니다.
그렇기 때문에 과거 문서 내용을 불러오는 유일한 방법은 사본으로 별도 저장하는 불편한 작업입니다.
▶ 지금 해보세요
notes폴더의study-log노트를 엽니다.- 노트 내용 전체를 선택해 복사합니다.
notes폴더에study-log 0728이라는 새 노트를 만들고 붙여넣습니다.
오늘 날짜를 이름에 붙여 오늘 상태의 보관본을 만든 것입니다.- 원본
study-log노트로 돌아가 문장 하나를 수정합니다.
지금까지 만든 노트 상태
study-notes/
└── notes/
├── study-log.md # ✏️ 방금 문장 하나 수정
└── study-log 0728.md # 🗸 오늘 상태의 사본
1.2 문서를 사본으로 저장할 때 불편 확인하기
이제 notes 폴더에는 이름이 비슷한 노트가 두 개 있습니다. 이 상태에서 세 질문에 답해 보세요.
- 두 노트 중 어느 것이 최신입니까? 일주일 뒤에도 파일 이름만 보고 알 수 있습니까?
- 두 노트는 정확히 어디가 다릅니까? 알아내려면 두 노트를 나란히 열고 직접 비교하는 방법뿐입니다.
- 사본을 만들기 전인 오늘 아침 상태로 돌아갈 수 있습니까? 그 시점의 사본이 없으므로 돌아갈 수 없습니다.
사본 저장의 불편은 크게 세 가지로 정리됩니다.
- 파일이 계속 쌓입니다.
- 사본끼리 비교하기 어렵습니다.
- 사본이 없는 시점으로는 돌아갈 수 없습니다.
"소스 코드로 쓰여진 문서"를 매일 고치는 개발자들에게는 이 불편이 훨씬 부담스러웠고, 그래서 만들어진 도구가 Git 입니다.
⚠ 주의: 확인이 끝났으면 체험용 study-log 0728 노트는 삭제하세요. 남겨 두면 12강에서 저장소를 만들 때 체험용 사본까지 함께 커밋됩니다.
2. Git 저장 방식 확인하기
→ 문서·게임의 저장 방식과 Git의 저장 방식을 대조합니다.
2.1 문서의 저장과 불러오기 방식
저장과 불러오기는 우리에게 매우 익숙한 기능입니다.
하지만 이 익숙한 기능에 대해 깊게 고민해 본 적은 아마 드물 것입니다.
Git과 GitHub를 제대로 이해하기 위해, 먼저 '저장'과 '불러오기'라는 기본 개념부터 차근차근 짚고 넘어가 봅시다.
2.1.1. 사본 저장과 불러오기 문제 확인
문서 편집기에서 "저장"은,
기본적으로 지금 보이는 내용을 하나의 파일에 덮어쓰는 동작입니다.
문서 편집기에는 "불러오기"는
별도의 동작이 없고, 사본 파일을 여는 것이 곧 불러오기입니다.
만약 이전 상태로 돌아가려면
미리 사본 파일로 만들어 두었어야 하고,
사본을 만들지 않은 시점은 다시 열 방법이 없습니다.
하지만 매번 작업할 때마다 일일이 사본을 만들어 두는 것은 번거로울 뿐만 아니라 결코 일반적인 방식이 아닙니다.
2.1.2. 게임 저장과 불러오기 비교
반면 게임의 "저장"은,
기본적으로 지금 시점의 상태를 새로운 파일로 만드는 동작입니다.
만약 보스전 앞에서 저장하면 게임은 그 순간의 상태(캐릭터 위치, 체력, 진행 상황)를 저장 지점 하나로 기록합니다.
보스전에서 패배한 뒤 "불러오기"를 실행하면 게임은 저장해 둔 시점의 상태로 되돌아갑니다. 저장 이후에 진행한 내용(패배로 끝난 전투)은 사라지고, 저장 지점의 상태에서 다시 시작합니다.
Git이 채택한 방식은 문서의 저장이 아니라, 게임의 저장 방식에 가까우면서, 하나의 파일에서 저장합니다.
다음 절에서 이 대응 관계를 Git의 실제 동작으로 확인합니다.
2.2 Git 의 저장 방식
Git은 내 컴퓨터에 설치해 문서를 저장하는 프로그램입니다.
문서 편집기이나 게임과 달리, 사본이라는 추가 파일을 별도로 저장하는 것이 아니라, 저장하고 싶은 시점마다 하나의 저장 지점으로 기록합니다.
이때 사본 파일은 생기지 않습니다.
마치 문서 편집기처럼 최신 파일 하나만 보이지만, 저장 지점의 기록은 Git이 폴더 안쪽에서 따로 관리합니다.
저장 지점을 식별하기 위해, 설명을 붙여 두고, 나중에 그 설명을 보고 되돌아갈 시점을 고릅니다.
| 구분 | 문서의 사본 저장 | 게임의 저장 지점 저장(Git) |
| 저장할 때 생기는 것 | 새 파일이 하나 더 생긴다 | 저장 지점 기록이 한 건 남는다. 파일은 그대로 하나다 |
| 시점을 구분하는 방법 | 파일 이름에 붙인 날짜 | 저장 지점마다 붙인 한 줄 설명 |
| 과거로 돌아가기 | 사본을 만들어 둔 시점만 가능 | 기록을 남긴 모든 시점 가능 |
| 폴더의 상태 | 사본이 쌓여 최신 파일을 찾기 어렵다 | 최신 파일만 보인다 |
시점마다 기록을 남기면 사본 방식만큼 용량이 늘 것 같지만, 그렇지 않습니다. Git은 저장할 때 바뀐 파일만 새로 저장합니다.
바뀌지 않은 파일은 다시 복사하지 않고, 이전 기록에 저장해 둔 내용을 그대로 가리킵니다. 저장하는 내용은 압축해서 보관합니다.그래서 기록이 수천 건 쌓여도, 폴더 전체를 수천 번 복사한 것보다 훨씬 작은 용량을 차지합니다.
✔ 용어 : Git이 기록을 관리하는 폴더를 저장소(repository)라고 부릅니다. 저장 지점의 기록 한 건을 커밋(commit)이라고 부릅니다. 일반적인 파일 저장과 구분하기 위해 이처럼 별도의 용어를 사용하는 이유가 있습니다.
저장소(Repository)는 단순히 파일만 모아두는 곳이 아니라 프로젝트의 '모든 변경 시점'을 기억하는 공간이기 때문입니다.
또한, '저장(Save)'이 파일 하나를 덮어쓰는 작업이라면, '커밋(Commit)'은 프로젝트 전체의 특정 시점을 기록하는 일입니다.
3. GitHub 공유 방식 확인하기
→ 공개 저장소 페이지를 열어 화면 구성 세 가지를 찾습니다.
3.1 GitHub이 해결하는 문제 확인하기
Git 까지만 쓰면 기록은 여전히 내 컴퓨터 안에 있습니다.
문서를 과거 시점으로 되돌리기 문제는 해결되지만, PC 고장 문제와 공유 문제는 그대로 남습니다.
GitHub은 이 남은 두 문제를 해결하는 인터넷 서비스입니다. 내 컴퓨터의 Git 저장소를 인터넷 서버에 올려 보관합니다.
올린 저장소는 누구나 웹 브라우저로 볼 수 있는 페이지로 표시됩니다.
문서를 구글 드라이브에 올려 보관하고 공유하는 것과 같은 구조입니다.
다른 점은 올라가는 대상이 Git 저장소라는 것입니다.
파일만 올라가는 것이 아니라, 커밋이라는 시점이 저정된 기록까지 함께 올라갑니다.
전 세계 개발팀 대부분이 이 방식으로 소스코드를 보관하고 공유합니다.
3.2 GitHub 공개 저장소 살펴보기
실제 GitHub 모습을 하나만 열어 봅니다.
브라우저에서 다음 주소를 여세요. 웹 페이지 디자인에 널리 쓰이는 개발 프로젝트의 저장소입니다.
https://github.com/twbs/bootstrap
페이지는 영어로 표시됩니다. 오늘 확인할 것은 글의 내용이 아니라 화면의 구성입니다.
▶ 지금 해보세요
- 주소와 화면 맨 위의
twbs/bootstrap을 찾습니다.계정이름/저장소이름형식입니다. GitHub에 올라온 저장소는 모두 이런 주소를 갖습니다. - 화면 가운데의 파일과 폴더 목록을 찾습니다. 이 프로젝트를 만드는 개발자들 컴퓨터의 폴더가 그대로 인터넷에 올라와 있는 것입니다.
- 파일 목록 아래의 긴 소개 문서를 찾습니다. 폴더 안
README.md파일의 내용이 첫 화면에 자동으로 표시된 것입니다. 학습 단위 1에서 작성해 온 마크다운 파일이 여기서 이렇게 쓰입니다.
지금 로그인을 하지 않았는데도 이 페이지가 전부 보입니다.
공개 저장소는 계정이 없는 사람을 포함해 누구나 볼 수 있습니다.
✔ 정리: 13강에서 자기 저장소를 공개로 만들 때 이 성질을 다시 판단하게 됩니다.
4. Obsidian, Git, GitHub 구조 확인
→ 오늘 확인한 내용의 사용 구조를 확인해봅니다.
5. 내 학습 기록에 대입해 보고 11강으로 넘기기
→ 오늘 확인한 내용을 자기 상황에 옮겨 적고 공개 범위를 판단합니다.
5.1 study-log 노트에 세 가지 적기
오늘 확인한 내용을 자기 상황에 옮겨 적습니다.
▶ 지금 해보세요
study-log노트에### 10강. Git과 GitHub 확인절을 만듭니다.- 지금까지 만든 노트 중에서, 며칠 전 상태로 되돌리고 싶었던 적이 있는 파일이 있는지 적습니다. 있었다면 어느 노트인지 함께 적습니다.
- Git과 GitHub 중 어느 것이 내 컴퓨터에서 동작하고, 어느 것이 인터넷 서비스인지 한 줄로 구분해 적습니다.
- 내
study-notes폴더가 방금 본 저장소처럼 인터넷에 공개된다면, 먼저 지워야 할 내용이 있는지 적습니다.
⚠ 주의: 세 번째 질문은 13강 실습 전에 반드시 답해 두세요. 저장소를 공개로 만들면 올린 내용은 누구나 볼 수 있습니다. 나중에 파일을 지워도 커밋 기록에는 남습니다.
5.2 확인한 내용 정리하고 11강으로 넘기기
다음 세 가지가 확인되면 오늘 학습이 끝난 것입니다.
| 확인 항목 | 기대 결과 | 확인 방법 |
| 사본 저장 체험 | 문제와 해결책에 각각 답할 수 있고 체험용 사본 노트가 삭제되어 있음 | Obsidian 파일 목록 확인 |
| 두 도구 구분 | Git과 GitHub 중 어느 것이 내 컴퓨터에서 동작하는지 한 줄로 적혀 있음 | study-log 노트 확인 |
| 공개 범위 판단 | 공개 전에 지울 내용이 있는지 판단한 결과가 적혀 있음 | study-log 노트 확인 |
→ 다음 개별 강의
11강에서는 오늘 구분한 두 도구를 사용하기 위한 준비를 합니다. GitHub 계정을 만들고, 인증에 사용할 개인 접근 토큰을 발급하고, Obsidian에 Git 플러그인을 설치합니다. 12강에서는 study-notes 폴더를 저장소로 만들어 지금까지 작성한 노트를 첫 커밋으로 남기고, 13강에서 그 커밋을 GitHub에 올립니다. 오늘 본 것과 같은 구성의 페이지가 자기 계정 아래에 생깁니다.