소프트웨어 개발을 공부하기 위해서 가장 먼저 배워야 하는 기술이라면 무엇일까요?
여러 의견이 있을 수 있겠지만, 개발을 하기 위해서는 팀과 함께 작업하는 협업이 필수적이고 이를 수월하게 하려면 협업 툴에 대해서 완벽하게 숙지하고 있는 것이 좋을것입니다.
또 버전 관리를 제대로 하지 않는다면, 코드를 잘 짰다고 생각했는데, 프로젝트가 엉망이 되거나, 이전 상태로 복구하지 못해 난감해질 수 있겠죠.
이런 문제를 해결하기 위해, 그리고 협업을 효율적으로 진행하기 위해 개발자들에게는 필수 도구인 Git이 필요합니다.
그래서 첫 TIL 글인 이번 글에서는 Git의 기초 개념부터 실무에서 자주 사용하는 명령어까지 살펴보며, 프로젝트 관리를 위한 탄탄한 기초를 다질 수 있도록 해보겠습니다.
Git의 기초 개념
Git이란?
Git은 분산 버전 관리 시스템(DVCS)입니다.
분산 버전 관리 시스템 이란?
여러 개발자가 동시에 작업하더라도 각자의 작업을 독립적으로 관리하고, 필요할 때 중앙 서버나 다른 개발자의 작업과 통합할 수 있는 강력한 도구입니다.
로컬 저장소(Local Repository): 내 컴퓨터에 저장된 프로젝트.
원격 저장소(Remote Repository): GitHub, GitLab 등 서버에 저장된 프로젝트.
분산 버전 관리 시스템: 왜, 그리고 어떻게 가능한가?
중앙집중식 버전 관리(Centralized Version Control System, CVCS)는 서버에 모든 데이터가 저장되며, 사용자는 서버에서 데이터를 가져와 작업을 수행합니다. 하지만 서버가 다운되거나 네트워크 연결이 끊기면 작업이 중단될 수 있다는 단점이 있습니다.
분산 버전 관리(Distributed Version Control System, DVCS)는 이와 달리, 각 사용자가 로컬 저장소에 전체 프로젝트의 히스토리를 복제(Clone)하여 작업할 수 있습니다. 이는 다음과 같은 특징 덕분에 가능합니다:
- 로컬 저장소 복제:
분산 버전 관리 시스템에서는 서버의 데이터를 로컬 컴퓨터로 완전 복제합니다. 각 사용자는 독립적으로 작업하며, 인터넷 연결 없이도 프로젝트를 관리할 수 있습니다. - 분리된 작업 흐름:
로컬에서 변경 사항을 저장(Commit)하고, 필요할 때만 원격 저장소와 동기화(Push, Pull)합니다. 이를 통해 작업 간섭을 최소화하고 효율성을 높일 수 있습니다. - 강력한 병합 기능:
Git은 브랜치와 병합(Merge)을 통해 여러 사용자가 동시에 작업하더라도 충돌을 최소화하고 변경 사항을 통합할 수 있도록 설계되었습니다.
여기서 궁금한 점이 생겨서 Chat GPT를 통해서 여러 질문을 해보았습니다. 분산 버전 관리 시스템은 어떻게 서버의 데이터를 완전 복제 할 수 있는지가 궁금해졌습니다. 중앙 집중식 버전 관리에서도 서버 데이터를 완전 복제 할 수 있다면 분산 버전 관리와 크게 다르지 않을텐데..?
Chat GPT Q: 분산 버전 관리 시스템은 어떻게 로컬 저장소 "전체"를 "완전복제" 할 수 있는거야? 중앙 집중식 관리도 로컬 저장소에 완전 복제 할수있다면 분산 버전 관리 시스템과 다르지 않은거 아니야?
Chat GPT A:
중앙 집중식 버전 관리 시스템(CVCS)
중앙 집중식 시스템은 프로젝트의 최신 상태만 로컬로 가져옵니다. 로컬 저장소에 저장되는 데이터는 보통 작업 디렉토리와 최신 상태 파일에 국한됩니다. 예를 들어:
- 서버에는 프로젝트의 모든 버전 기록(변경 내역)이 저장되어 있습니다.
- 사용자는 최신 버전을 서버에서 받아오고, 파일을 수정합니다.
- 변경 사항을 서버로 업로드하면(Commit) 서버에 기록이 저장됩니다.
즉, 로컬 저장소에는 최신 상태의 파일만 있고, 전체 변경 이력은 서버에만 존재합니다. 서버가 다운되거나 손상되면 이력 복구가 불가능한 경우가 많습니다.
분산 버전 관리 시스템(DVCS)
분산 버전 관리 시스템은 중앙 집중식 시스템과 달리, 프로젝트의 전체 히스토리를 로컬 저장소로 복제합니다. 이를 가능하게 만드는 두 가지 특징이 있습니다:
- 이력 데이터의 구조
Git은 데이터를 단순히 파일 단위로 저장하지 않고, 스냅샷(snapshot) 방식으로 관리합니다.- 커밋마다 프로젝트 전체의 파일 상태를 저장하는 대신, 변경된 파일(차이점)만을 추적하고 압축합니다.
- 이를 통해 각 커밋은 독립적인 ID(SHA-1 해시)로 참조되며, 변경 이력과 관계가 철저히 관리됩니다.
- 로컬 저장소와 원격 저장소의 동기화
Git에서 로컬 저장소를 생성할 때(git clone), 원격 저장소에 저장된 모든 커밋과 브랜치 기록이 로컬로 복제됩니다.- 로컬 저장소는 원격 저장소와 동일한 히스토리를 가지고 있으므로, 인터넷 연결 없이도 독립적으로 모든 커밋과 변경 내역을 조회하거나 복구할 수 있습니다.
- 이 데이터는 원격 저장소와의 동기화를 통해 최신 상태를 유지합니다.
분산 버전 관리와 중앙 집중식 관리의 차이점
특징중앙 집중식 버전 관리 (CVCS)분산 버전 관리 (DVCS)
로컬 저장소 내용 | 최신 상태의 파일 (전체 히스토리는 서버에만 저장됨). | 최신 상태 + 전체 히스토리를 로컬에 저장. |
히스토리 복구 가능 여부 | 서버 다운 시 복구 불가능. | 로컬 저장소만으로도 복구 가능. |
작업 방식 | 항상 서버와 연결 필요. | 인터넷 연결 없이도 독립 작업 가능. |
협업 효율성 | 병합이나 충돌 처리가 서버 중심으로 이루어짐. | 브랜치/병합 처리 방식이 로컬-원격 간 분리됨. |
여기서 가장 중요한 부분은 분산 버전관리를 가능하게 하는 기술, 스냅샷 방식으로 관리한다는 부분인 것 같습니다.
커밋(commit, 변경사항을 저장하는 단위)마다 전체의 파일 상태를 저장하는 것이 아니라 변경된 파일(차이점) 만을 추적하고 이를 hash를 이용하여 압축하여 관리함으로써 전체 프로젝트를 복제하더라도 용량 문제가 생기지 않고 완전 복제가 가능한것이죠!
그렇다면 Hash? 가 뭐야?
각 커밋(변경사항)을 SHA-1 해시로 참조된다고 하는데, 이게 무슨 뜻인지 다시 Chat GPT에게 물어보겠습니다.
Chat GPT Q: 커밋 참조에 사용된다는 SHA-1 해시는 뭐야?
Chat GPT A:
SHA-1이란?
SHA-1(Secure Hash Algorithm 1)은 160비트(40자리 16진수) 길이의 해시 값을 생성하는 알고리즘입니다. 입력 값의 크기와 상관없이 고정된 크기의 해시 값을 출력하며, 다음과 같은 특징을 가집니다:
- 고유성
- 서로 다른 데이터는 각각 고유한 해시 값을 가집니다.
- Git은 이 속성을 활용해 커밋, 파일, 트리 등 객체를 식별합니다.
- 비가역성
- SHA-1 해시는 일방향 함수로, 생성된 해시 값을 통해 원본 데이터를 역으로 계산할 수 없습니다.
- 작은 변경에 민감
- 입력 값에 아주 작은 변화라도 생기면 완전히 다른 해시 값이 생성됩니다.
예:"hello world" → SHA-1: 2ef7bde608ce5404e97d5f042f95f89f1c232871"hello_world" → SHA-1: 6adfb183a4a2c94a2f92dab5ade762a47889a5a1
- 입력 값에 아주 작은 변화라도 생기면 완전히 다른 해시 값이 생성됩니다.
SHA-1 이라는 건 어떤 데이터를 이용해서 특정한 코드를 만들어내는 알고리즘인 것 같네요!
각 데이터는 고유한 해시 값을 생성하고 이 해시 값을 이용하여 데이터를 만들어 내는 역산은 불가능하기 때문에 해시 값을 이용하면 어떤 특정 데이터와 내 원본 데이터가 똑같은지 간단하게 해시 값을 비교해서 알아내는 것이 가능하겠네요.
그러니까, git은 해시값을 이용해서 전체 데이터를 비교하는 것이 아니라 데이터로 만들어진 해시 값을 비교해서 추적하기 때문에 변경사항을 추적하는데 데이터 전체가 필요하지도 않고 빠르게 데이터를 추적, 관리할 수 있는 것입니다.
이런 관리 방식 때문에 분산 버전 관리가 가능하다는 게 git 기능의 핵심인 것 같습니다!
해시 관련 내용에 대해서 더 말씀드릴 내용이 있지만 이건 이후 글에서 다시 언급드리겠습니다.
다시 Git 으로 돌아오면,
Git과 GitHub의 차이
혼동하기 쉬운 두 용어의 차이점
Git: 버전 관리 도구 자체
GitHub: Git을 활용해 원격 저장소를 관리하고 협업할 수 있는 플랫폼, 다양한 플랫폼이 존재하지만 Github가 가장 유명합니다.
그러면 이제 실제로 Git을 설치하고 사용하는 방법에 대해 알아보겠습니다.
Git 설치 및 환경 설정
Git은 운영 체제에 따라 설치 방법이 다릅니다.
Windows: Git 다운로드 링크: https://git-scm.com/downloads/win
macOS: Homebrew로 설치
brew install git
Linux: 패키지 관리자를 통해 설치
sudo apt-get install git
windows는 링크에서 설치파일을 다운로드 받아서 설치하시면 되고, macOS와 Linux의 경우 터미널에서 해당 명령어를 이용하면 간단하게 설치 할 수 있습니다.
Git 최초 설정
Git을 설치한 후, 전역 설정을 통해 사용자 정보를 등록해야 합니다. 이 정보는 이후 커밋 기록에 포함됩니다.
이 커밋을 작성한 사람이 누군지에 대한 정보를 반드시 작성해 주어야 합니다.
사용자 이름 설정
$ git config --global user.name "Your Name"
"Your Name" 부분에 이름 작성해주시고,
사용자 이메일 설정
$ git config --global user.email "youremail@example.com"
"youremail~" 부분에 이메일 정보를 작성해주시면 완료입니다.
Git의 기본 흐름
Git은 Working Directory → Staging Area → Repository라는 세 가지 영역으로 나뉘어 관리됩니다.
각각의 단계에서 파일의 상태를 추적하며, 명령어를 통해 관리합니다.
주요 명령어
1. 저장소 초기화
Git으로 프로젝트를 관리하려면 먼저 저장소를 초기화해야 합니다.
$ git init
위 코드를 작성하고 나면 터미널에 (master)라는 branch 이름이 표시되기 시작합니다.
예)
user@user /Desktop (master) $
2. 상태 확인
현재 파일들의 상태를 확인합니다.
$ git status
현재 git에서 관리되고 있는 파일들의 상태를 표시해줍니다.
satging Area에 올라가있는지, 추적되고 있는지, 파일에 변경사항이 있는지 등을 표시해 줍니다.
3. 파일 추가
변경된 파일을 Staging Area로 이동시킵니다.
$ git add 파일명
Staging Area는 commit(변경사항)을 반영할 파일들을 올려놓는 공간입니다. commit은 이 staging area에 있는 파일 리스트를 저장소로 옮겨주는 역할을 합니다.
간단하게 현재 디렉토리에서 모든 변경사항을 staging area에 올리고 싶다면,
$ git add .
위 명령어로 한꺼번에 staging area에 올릴 수 있습니다.
4. 커밋하기
Staging Area에 있는 변경 사항을 저장소에 저장합니다.
$ git commit -m "커밋 메세지"
커밋에는 변경사항이 어떤 내용인지를 설명해주는 커밋 메세지가 필수적입니다. git은 이 commit 메세지도 함께 hash 코드로 변환하기 때문에 커밋 메세지가 조금이라도 달라진다면 hash 코드가 완전히 달라지게 됩니다.
일반적으로 커밋 메세지는 프로젝트 팀별로 일정한 규칙을 정해서 작성합니다.
관련 내용은 이후 다른 글로 작성해보겠습니다.
5. 변경 이력 보기
변경된 파일들의 기록을 확인합니다.
$ git log
현재 git 저장소에서 커밋한 기록들을 보여줍니다. 만약 log가 너무 길어서 한꺼번에 보기 힘들다면,
$ git log --oneline
위 명령어를 통해서 한 개의 커밋마다 한줄로 표기할 수도 있습니다.
.gitignore 파일 생성
gitignore 파일은 Git이 특정 파일이나 폴더를 추적하지 않도록 설정하는 파일입니다. 예를 들어, 비밀번호가 포함된 파일이나 대용량 로그 파일은 .gitignore에 추가해 관리에서 제외할 수 있습니다.
1. 먼저 git 저장소 최상단 directory에 .gitignore 파일을 생성해 줍니다.
$ touch .gitignore
위와 같은 명령어를 통해서도 작성할 수 있고, 간단하게 GUI를 이용해서 작성하셔도 상관없습니다.
2. .gitignore 파일에 git 추적에서 제외할 파일 이름을 작성해줍니다.
ex. secret.txt 파일을 추적에서 제외하고 싶다면
.gitignore
secret.txt
단순히 파일이름을 작성하고 저장해주면 git에서 더이상 secret.txt 파일을 추적하지 않습니다.
단, 이미 secret.txt 파일을 commit해서 git이 파일을 추적하기 시작한 이후에는 gitignore에 작성하더라도 추적에서 제외되지 않습니다. 이 경우에는
$ git rm --cached secret.txt
위와 같은 명령어를 이용하면 더이상 git에서 secret.txt 파일을 추적하지 않게 됩니다.
gitignore 파일은 비밀번호나 대용량 로그 파일뿐 아니라 개발 과정에서 자동 생성되는 숨김 파일도 포함하는 것이 좋습니다.
이를 손쉽게 생성할 수 있도록 돕는 웹사이트를 소개합니다.
gitignore를 자동적으로 생성해주는 웹사이트
https://www.toptal.com/developers/gitignore
위 웹사이트에서 개발환경에서 사용되는 운영체제, 프로그램 언어, IDE 등을 넣어주면 자동으로 해당 환경에서 주로 사용하는 .gitignore 양식을 제공해줍니다.
마무리
이번 글에서는 간단하게 git에 대한 기초 개념과 로컬 저장소에서 git을 이용해서 버전 관리를 하는 명령어들에 대해서 알아보았습니다.
다음 글에서는 github를 이용해서 원격 저장소에 연결하는 방법과 원격 저장소 사용시에 일어날 수 있는 실수들에 대해서 작성해보도록 하겠습니다.
이 글에서 다룬 내용 외에도 Git 사용과 관련해 궁금한 점이 있거나, 잘못된 부분이 있다면 댓글로 자유롭게 알려주세요. 여러분의 피드백은 글을 더 발전시키는 데 큰 도움이 됩니다! 😊
'TIL > git' 카테고리의 다른 글
Git 고급 사용법과 협업: 실무에서 꼭 알아야 할 핵심 개념 (0) | 2025.01.20 |
---|