버전 관리는 왜 중요할까?
버전 관리라고 하면 많은 사람들이 Git부터 떠올리지만, 사실 우리는 Git을 배우기 훨씬 전부터 버전 관리를 해오고 있었다.
과제를 제출할 때 파일 이름을 ‘최종’, ‘찐최종’, ‘찐찐최종’처럼 저장했던 경험이 대표적이다.
이는 체계적이지는 않지만, 작업 이력을 남기고 되돌아가기 위한 시도라는 점에서 버전 관리의 본질과 크게 다르지 않다.
버전 관리는 작업을 안전하게 보호하고, 실수를 두려워하지 않게 만드는 기반이다.
특히 코드나 연구 결과처럼 반복적인 수정과 실험이 필요한 작업에서는 선택이 아니라 필수에 가깝다.
버전 관리의 기능은 크게 4가지로 나눌 수 있다.
- 스냅샷 기능 : 작업 시점마다 프로젝트의 전체 상태를 저장한다.
어떤 시점에 무엇을 하고 있었는지에 따라 해당 시점의 상태를 그대로 보존할 수 있다. - 시간 여행 : 연구나 개발 도중 잘못된 방향으로 진행되었을 경우, 이전에 잘 동작하던 상태로 되돌아갈 수 있다.
- 변경 추적 : 무엇을, 언제, 누가, 왜 변경했는지를 기록한다. 커밋 메시지를 통해 변경 의도와 이력을 확인할 수 있다.
- 협업 지원 : 여러 연구원이나 개발자가 동시에 작업하더라도 충돌을 관리하며 효율적으로 협업할 수 있다.
버전 관리를 돕는 도구들 (1990~현재)
중앙 집중식 버전 관리 시스템의 등장
초기의 버전 관리 시스템은 중앙 집중식 구조를 가지고 있었다. 대표적인 예가 CVS와 Subversion이다.
1. CVS (1990년대)
CVS는 1990년대에 등장한 최초의 대중적인 버전 관리 도구 중 하나로, 모든 변경 이력을 중앙 서버에 저장했다.
하지만 원자성이 부족해 여러 파일을 동시에 수정할 때 일관성이 깨질 수 있었고, 브랜치 관리도 매우 불편했다.
2. Subversion(SVN, 2000년대)
SVN은 이러한 문제를 개선해 등장했다.
여러 파일을 한 번에 커밋할 때 전체가 성공하거나 전체가 실패하는 원자성을 지원했고,
이진 파일 관리와 파일 이름 변경 추적도 가능해졌다.
Git이 등장하기 전까지는 가장 널리 사용되던 도구였으며, 현재도 일부 대기업에서는 SVN을 사용하고 있다.
분산 버전 관리로의 전환
중앙 집중식 방식의 가장 큰 문제는 중앙 서버에 장애가 발생하면 작업 자체가 불가능해진다는 점이다.
이 한계를 극복하기 위해 분산 버전 관리 시스템이 등장했다.
3. Git의 등장 (2005년~)
Git은 2005년 리눅스 커널 개발을 위해 만들어진 분산 버전 관리 시스템이다.
각 개발자가 프로젝트 전체 이력을 로컬에 가지고 있기 때문에, 네트워크 연결 없이도 커밋과 브랜치 작업이 가능하다.
이후 인터넷이 연결되었을 때 변경 사항을 한 번에 공유하면 된다.
Git이 표준이 된 이유
이때 Git이 표준이 된 가장 큰 이유는 분산 버전 관리 구조를 통해 중앙 서버에 의존하지 않고도, 모든 개발자가 전체 프로젝트 이력을 로컬에 보유할 수 있어 속도와 안정성이 뛰어나기 때문이다.
여기에 브랜치 생성과 병합이 매우 가볍고 효율적으로 설계되어 있어, 기능 개발·버그 수정·실험적 작업을 병렬로 수행하더라도 코드 충돌을 체계적으로 관리할 수 있다.
결정적으로 GitHub의 등장으로 오픈소스 협업 문화가 폭발적으로 성장하면서 코드 공유, 이슈 관리, 코드 리뷰, CI/CD 연계까지 하나의 플랫폼에서 가능해졌고, 이 생태계 확장이 Git을 사실상의 산업 표준으로 굳히는 결정적인 역할을 했다.
Git과 GitHub의 차이점
Git은 버전 관리를 위한 분산 버전 관리 도구. 리눅스 커널의 창시자인 Linus Torvalds가 직접 개발했다.
Git은 파일의 변경 이력을 기록하고, 특정 시점의 상태로 되돌아갈 수 있도록 해준다.
개인 개발부터 대규모 협업까지 폭넓게 사용되며, 현재 가장 표준적인 버전 관리 도구로 자리 잡았다.
반면 GitHub은 Git 저장소를 클라우드에서 관리할 수 있도록 제공하는 웹 서비스다.
Git은 로컬 컴퓨터에 설치되어 동작하는 도구이고, GitHub는 인터넷 상에 존재하는 웹 기반 플랫폼이라는 점에서 차이가 있다.
GitHub는 단순한 저장소 호스팅 서비스를 넘어 개발자 커뮤니티의 중심 공간으로 발전했다.전 세계 1억 명이 넘는 개발자가 활동하고 있으며, 오픈소스 프로젝트, 협업, 포트폴리오 공유의 핵심 플랫폼으로 활용되고 있다.
Git의 기본 구조
Git은 크게 네 가지 영역으로 구성된다.
- 첫째, Working Directory.
실제로 코드를 작성하고 수정하는 작업 공간이다.
Visual Studio Code와 같은 편집기에서 작업하는 디렉토리가 여기에 해당한다. - 둘째, Staging Area.
커밋할 변경 사항을 선별해 올려두는 중간 단계 공간이다. 무대에 올릴 배우를 고르는 과정에 비유할 수 있다.
이 단계가 필요한 이유는 커밋을 논리적으로 분리하기 위해서다.
예를 들어 10개의 파일을 수정했는데, 5개는 새로운 기능 추가이고 5개는 버그 수정이라면 이를 하나의 커밋으로 묶는 것은 관리 측면에서 좋지 않은데, 이때 Staging Area를 활용하면 기능 추가 커밋과 버그 수정 커밋을 분리해 기록할 수 있다. - 셋째, Local Repository.
커밋된 스냅샷과 변경 이력이 저장되는 공간이다.
Git 저장소에는 .git 디렉토리가 존재하며, 이 안에 모든 히스토리가 기록된다. Local Repository는 내 컴퓨터에 있는 저장소다. - 넷째, Remote Repository.
Local Repository에 있는 내용을 원격 서버에 업로드한 저장소다.
GitHub나 GitLab과 같은 서비스가 이에 해당한다.
이때 일반적인 흐름은 Working Directory에서 수정한 내용을 Staging Area에 올리고, 이를 Local Repository에 커밋한 뒤, 필요할 경우 Remote Repository로 푸시하는 방식이다.
Git checkout의 의미
Git checkout은 특정 커밋이나 브랜치의 상태를 Working Directory로 가져오는 명령이다.
과거의 상태로 돌아가 작업을 이어갈 수 있기 때문에, Git의 타임머신 기능에 해당한다고 볼 수 있다.
Git 명령어를 꼭 알아야 하는가
Git을 깊이 있게 사용하려면 명령어를 이해하는 것이 중요하다.
초기 Git은 터미널 기반으로만 사용 가능했기 때문에 명령어 숙지가 필수였다.
그러나 최근에는 pull, push, commit과 같은 기본 개념만 알고 있어도 충분히 활용할 수 있는 GUI 도구들이 많이 등장했다.
대표적으로 GitHub Desktop, SourceTree, TortoiseGit, gitk 등이 있다.
따라서 처음에는 개념 위주로 이해하고, 필요에 따라 명령어 사용 범위를 점진적으로 넓혀가는 방식이 효과적이다.
Git 설치 및 세팅 방법
Git 설치하기
Git 설치 : https://git-scm.com/
Git
git-scm.com
GitHub는 어떤 소스코드를 올리는 공간의 개념이라면,
이 소스코드를 내 컴퓨터에서 인터넷으로 올려주는 역할을 Git이 해주는 것이다.
오른쪽에 Download for Window로 들어가서, 나의 환경에 맞게 다운을 해준다.
Download 받고 쭉 Next 해주면 됨.
Git 세팅하기
Git Bash로 들어간다. (Window에서 검색하면 나옴)
여기서 다음 명령어를 친다
gksyb@DESKTOP-F990P95 MINGW64 ~
$ git config --global user.name "yourname"
gksyb@DESKTOP-F990P95 MINGW64 ~
$ git config --global user.email "youremail@gmail.com"
그리고 git config --list를 통해 user.name과 user.email이 제대로 입력되었는지 확인한다.
'Tool 활용법 > Git과 GitHub 활용법' 카테고리의 다른 글
| [Git 기초 2] Directory의 변경 이력 확인하기 (git diff, Git Graph) (0) | 2026.01.19 |
|---|---|
| [Git 기초 1] git으로 파일 추적 및 기록하기 (git init, git add, git commit) (0) | 2026.01.19 |
| GitHub의 역사 (Microsoft의 인수와 Copilot의 등장) (0) | 2026.01.19 |