Git

Git은 파일, 주로 소스 코드의 변경 이력을 기록하는 분산 버전 관리 시스템이다. 개발자마다 전체 이력을 포함한 저장소 사본을 통째로 복제하므로 커밋, 브랜치 생성, 과거 버전 확인이 서버 없이 로컬에서 이뤄진다. 커밋은 스냅샷과 부모 커밋 포인터를 함께 저장하며, 덕분에 이력을 거슬러 오르내리고 되돌리는 비용이 낮다. 브랜치는 가벼운 포인터라 기능이나 수정 단위로 만들었다가 작업이 끝나면 병합한다. GitHub와 GitLab 같은 호스팅 서비스가 그 위에 풀 리퀘스트, 코드 리뷰, 이슈 관리, 푸시마다 도는 파이프라인을 얹어 협업을 완성한다. 오늘날 개발 워크플로는 사실상 Git을 전제로 하며, AI 코딩 도구도 마찬가지다. 기계가 쓴 변경을 사람이 검토하고 되돌릴 수 있는 근거가 결국 깔끔한 커밋 이력이기 때문이다. 흔한 실수는 Git을 백업 도구처럼 쓰는 것이다. 오래 방치한 브랜치는 본류와 멀어져 병합 충돌을 키우고, API 키 같은 비밀값은 지운 뒤에도 이력에 남는다.

Git is a distributed version control system that records the history of changes to a set of files, most often source code. Every developer clones a full copy of the repository including its complete history, so committing, branching, and inspecting past versions all happen locally without contacting a server. A commit stores a snapshot plus a pointer to its parent, which is what makes history traversable and reverts cheap. Branches are lightweight pointers, so teams create one per feature or fix and merge it back when the work is done. Hosting services add collaboration on top of the core tool: GitHub and GitLab provide pull or merge requests, code review, issue tracking, and pipelines that run on every push. Nearly every modern development workflow assumes Git, and AI coding tools depend on it too, since a clean commit history is what lets a developer inspect and undo machine-written changes. The common pitfall is treating Git as a backup service. Long-lived branches drift far from the main line and produce painful merge conflicts, and secrets such as API keys stay in history even after they are deleted from the working tree, which is why teams keep branches short and scan commits before pushing.