Git · GitHub

Git이란?

Git을 쓰기 시작하면 팀의 파일 관리 습관부터 바뀝니다. '앱_최종.py', '앱_최종_진짜최종.py'처럼 복사본을 늘려 두던 방식 대신, 파일은 하나로 두고 변경 이력만 아래로 쌓입니다. 누가 언제 어느 줄을 왜 고쳤는지가 커밋 메시지와 함께 남으니, 사고가 나도 추궁이 아니라 기록 조회의 문제로 정리됩니다. 혼자 만든 코드를 남에게 넘길 때도 이력 자체가 인수인계 자료가 됩니다.

Git과 GitHub는 한 단어처럼 붙어 다니지만 층이 다릅니다. Git은 내 노트북에서 도는 프로그램이고, GitHub는 그 결과물을 올려 두는 서버입니다. 같은 자리에 GitLab이나 Bitbucket을 쓰는 회사도 많습니다. 실무에서 필요한 개념은 넷입니다 — 커밋(저장 지점), 브랜치(본줄기를 건드리지 않는 작업용 갈래), 풀 리퀘스트(합치기 전 검토 요청), 머지(합치기). 저장소는 공개와 비공개 중 반드시 골라야 하고, 파일 하나당 100MB 제한이 있으며, 엑셀·이미지 같은 바이너리는 변경분 비교가 되지 않아 코드와 설정 파일 위주로 담는 편이 낫습니다.

AI로 코드를 만드는 상황에서는 커밋 단위가 곧 실험 단위입니다. 한 번에 기능 다섯 개를 시키고 커밋을 한 번만 남기면 어느 요청이 문제를 일으켰는지 가려낼 수 없으니, 요청 하나에 커밋 하나를 원칙으로 잡는 편이 안전합니다. GitHub 저장소는 배포 서비스와 바로 연결되기도 해서, 코드를 올리는 순간 실제 화면이 갱신되는 구조를 만들 수 있습니다. 이때는 올리는 행위가 곧 배포이므로 검토 없이 밀어 넣지 않는 습관이 필요합니다.

현장에서 가장 잦은 사고는 API 키나 DB 비밀번호를 코드에 적은 채 커밋해 공개 저장소에 올리는 일입니다. 나중에 파일에서 지워도 과거 커밋 안에는 그대로 남아 있어, 이력을 몇 줄만 뒤지면 다시 나옵니다. 두 번째 오해는 '깃허브에 올렸으니 백업은 끝났다'입니다. 커밋만 하고 push하지 않으면 그 기록은 여전히 노트북 안에만 있고, 기기가 고장 나면 함께 사라집니다. 세 번째는 커밋 메시지를 전부 '수정'으로 채우는 습관인데, 돌아갈 지점을 찾지 못하면 쌓아 둔 이력도 없는 것과 마찬가지입니다.