Git과 GitHub

1. 왜 버전 관리가 필요한가

파일을 그냥 덮어써 저장하면, 바로 이전 상태는 사라집니다. 문서를 고치다 망쳤을 때 "저장 전으로 되돌리고 싶다"고 느낀 적이 있을 겁니다. Git 은 저장할 때마다 '되돌아올 수 있는 지점'을 하나씩 남겨 두는 버전 관리 도구입니다. (이렇게 파일의 변경 이력을 지점마다 남겨 관리하는 것을 '버전 관리'라고 부릅니다.)

그냥 저장:  [ 최종본 ]                     ← 이전은 사라짐
Git:       [처음] → [중간] → [최종본]      ← 어느 지점으로든 되돌아갈 수 있음

타임머신처럼, 언제든 예전 지점으로 돌아가 볼 수 있게 해 줍니다.

2. commit 은 되돌아갈 수 있는 저장 지점

commit 은 "이 순간의 상태"를 통째로 찍어 남긴 저장 지점입니다. 각 commit 에는 그 순간 파일들의 스냅샷과, '무엇을 왜 바꿨나' 한 줄 메모가 담깁니다. 그래서 저장 지점 목록만 훑어도 언제 무슨 작업을 했는지가 보입니다.

gildong@server:~/my_project$ git log --oneline    # 저장 지점(commit) 목록
a1b2c3d  요약 화면에 안내 문구 추가       ← 각 줄이 되돌아갈 수 있는 한 지점
9f8e7d6  로그인 버튼 색 수정
3c2b1a0  프로젝트 초기 설정

commit 은 자주 찍을수록 좋습니다. 지점이 촘촘하면 잘못됐을 때 바로 직전으로 돌아가면 되니 잃는 게 적지만, 하루 종일 한 번도 안 찍었다면 문제가 났을 때 하루치를 통째로 잃을 수 있습니다.

3. 로컬과 원격(GitHub)

같은 작업 기록이 두 군데에 있을 수 있습니다.

[ 내 서버 · 로컬 ]  ── push(올리기) ──▶  [ GitHub · 원격, 팀 클라우드 ]
                    ◀── pull(내려받기) ──

• 로컬: 내 서버 안에만 있는 사본. commit 을 찍으면 일단 여기에만 쌓입니다.
• 원격(GitHub): 팀이 함께 쓰는 클라우드. '코드용 구글 드라이브'라고 보면 됩니다. GitHub 는 코드를 이 클라우드에 올려 여럿이 함께 쓰고 변경 이력까지 남기게 해 주는 서비스입니다.

단, 구글 드라이브처럼 자동으로 올라가지는 않습니다. push 하지 않으면 내 작업은 내 서버에만 있습니다.

gildong@server:~/my_project$ git status
Your branch is ahead of 'origin/master' by 3 commits.   ← commit 3개가 아직 내 서버에만(올리기 전)

commit 을 아무리 많이 찍어도 올리기 전까지는 팀 클라우드에 없고 백업도 안 된 상태입니다. 온보딩에서 "올리기 전엔 내 서버에만 남는다"고 한 게 이 얘기입니다.

4. 브랜치

나무에 몸통 '줄기'가 있고 거기서 '가지'가 뻗어 나오듯, Git 에도 팀의 완성된 코드가 흐르는 중심 줄기가 있습니다. 이 줄기가 master, 거기서 옆으로 쳐 낸 작업용 가지가 브랜치(branch)입니다. (이제부터는 익숙해지도록 줄기·가지 대신 master·브랜치라고 부릅니다.)

master 에서 브랜치가 갈라져 나와 작업하다, 다 되면 다시 master 에 합쳐집니다.

그냥 master 에서 바로 작업하면 안 되나요? 됩니다. 하지만 곧 후회합니다. master 는 그냥 코드 보관소가 아니라 실제 고객에게 배포되는 라인이기 때문입니다. 온보딩에서 배운 배포가 이 master 를 기준으로 나가므로, master 는 언제나 '지금 당장 배포해도 되는 멀쩡한 상태'여야 합니다.

혼자 일해도 이게 문제가 됩니다. 예를 들어 이런 상황입니다.

1. 금요일, 새 기능을 절반쯤 만들다 퇴근합니다. master 에는 반쯤 짠 미완성 코드가 쌓인 채입니다.
2. 월요일 아침, 고객이 "로그인이 안 돼요"라고 긴급 신고합니다. 급히 고쳐 배포해야 합니다.
3. 그런데 master 에 금요일에 만들다 만 기능이 섞여 있어, 급한 수정만 딱 떼어 배포할 수가 없습니다. 미완성 기능까지 딸려 나가 오히려 더 터집니다.

브랜치를 썼다면 이야기가 다릅니다. 미완성 기능은 브랜치 위에 얌전히 남고 master 는 늘 깨끗하니, 급한 버그는 master 에서 바로 고쳐 배포하고 하던 기능은 나중에 브랜치에서 마저 하면 됩니다. 실험도 마찬가지입니다. 새 방식으로 갈아엎어 보다가 "이건 아니다" 싶으면 브랜치째 버리면 그만이고, master 는 손도 안 댔으니 원래 그대로입니다. master 에서 직접 했다면 되돌리느라 진땀을 뺍니다.

여기에 더해, 애초에 Git 은 여럿이 함께 쓰는 협업 시스템입니다. 브랜치가 그 협업을 가능하게 합니다. 팀원마다 자기 브랜치를 하나씩 쳐서 각자 작업하면, 서로의 미완성 코드를 밟지 않고 나란히 진행하다가 다 된 것부터 master 에 합칩니다.

Claude 의 /develop 이 자동으로 브랜치를 만들어 작업하는 것도 이 때문입니다. 결과가 검증을 통과하면 master 에 합치고, 실패하면 브랜치째 버려 master 는 전혀 건드리지 않습니다. 실패한 시도가 멀쩡한 master 를 더럽히지 않는 것입니다.

5. 충돌(conflict)

앞에서처럼 여럿이 각자 브랜치에서 나란히 일하다 보면, 부딪히는 지점이 생깁니다. 두 사람이 같은 파일의 같은 줄을 서로 다르게 고친 뒤 각자 master 에 합치려 할 때입니다. Git 은 서로 다른 부분의 변경은 대개 알아서 합치지만, 똑같은 한 줄을 서로 다르게 바꿨다면 누구 것을 남길지 스스로 정할 수 없어, 두 버전을 이렇게 나란히 표시하고 멈춥니다. 이게 충돌입니다.

<<<<<<< 내 변경
버튼 색을 파랑으로
=======
버튼 색을 초록으로
>>>>>>> 남의 변경

충돌은 고장이 아니라 정상적인 되물음입니다. 겁먹지 말고 Claude 에게 "충돌 해결해줘"라고 맡기면 됩니다. 어느 쪽을 남길지 개념만 알면, 실제 정리는 Claude 가 대신 합니다.

충돌이 꼭 두 사람 사이에서만 나는 건 아닙니다. 혼자여도, 예를 들어 같은 저장소를 두 벌로(서로 다른 이름으로) 가져와 양쪽에서 같은 줄을 고친 뒤 합치면 똑같이 부딪힙니다. 우리처럼 중앙 서버 한 곳에서만 작업하면 이런 일은 드물지만, 원리는 같습니다. 갈라져 나온 두 갈래가 같은 자리를 다르게 건드리면 그게 충돌입니다.

그래서 브랜치가 중요합니다. 부딪힘은 브랜치를 master 에 합치는 순간에 드러나므로, 미리 브랜치에서 정리하면 master(배포 라인)는 안전합니다. 반대로 master 에서 곧장 작업했다면 이 충돌과 실수가 고객에게 나가는 라인 위에서 그대로 벌어집니다. 브랜치는 그 위험을 안전한 곳에 가둬 두는 장치입니다.

6. PR과 리뷰, 보호되는 저장소

PR(풀 리퀘스트)은 내 브랜치를 master 에 합치기 전에 검토를 받는 절차입니다.

내 브랜치를 PR(master 에 합쳐도 될까요?)로 올리면, 팀원이 확인·승인한 뒤 master 에 합쳐집니다.

바로 합치지 않고 한 번 걸러 실수를 막는 관문입니다. 이 관문을 반드시 거치도록 잠가 둔 저장소를 '보호되는 저장소'라고 합니다.

팀 전체가 공용으로 쓰는 핵심 자산(standarda-core, standarda-template)이 여기 해당합니다. 여러 프로젝트가 함께 의존하는 코드라, 한 사람의 실수가 모두에게 번지지 않도록 master 에 바로 못 올리게 막아 둔 것입니다. 반대로 보통의 개별 프로젝트 저장소는 보호가 없어 확인 후 바로 올려도 됩니다.

7. .gitignore

.gitignore 는 "이건 GitHub 에 올리지 마라"고 Git 에게 알려 주는 목록입니다. 프로젝트 폴더의 파일이 전부 클라우드에 올라가면 곤란한 것들이 있는데, 대표적으로 비밀키입니다.

# .gitignore : 이 목록에 적힌 것은 GitHub 에 올리지 않는다
.env             ← 비밀키가 든 파일
*.log            ← 로그 파일
__pycache__/     ← 프로그램이 만든 임시 파일

여기 이름을 적어 두면 Git 이 그 파일을 아예 없는 것처럼 무시해 올리지 않습니다. 무엇을 왜 숨겨야 하는지, 비밀키를 어떻게 다루는지는 다음 강의에서 자세히 다룹니다.

오늘 정리 + 다음

• 정리: Git 은 commit 으로 되돌아갈 지점을 남기는 도구입니다. 작업은 로컬에 쌓이고 push 로 원격(GitHub)에 올립니다. 브랜치로 master 와 분리해 작업하고, 같은 줄이 겹치면 충돌이 나며, master 에 합치기 전 PR 로 검토받습니다. 팀 공용 핵심은 보호되어 PR·승인이 필요합니다.
• 흔한 함정: push 를 잊는 것. commit 만 하고 push 를 안 하면 작업이 내 서버에만 남아 백업도 공유도 안 된 상태가 됩니다. 작업을 마쳤으면 push 까지 했는지 확인합니다.
• 다음 시간: 비밀키와 .env. 올리면 안 되는 값들을 어떻게 분리해 두는지, 개발 환경 구분과 함께 다룹니다.