1. 버전 관리 없이 생기는 문제: 파일을 그냥 복사하는 것은 왜 나쁜 생각인가
실제에서 흔히 겪는 상황부터 시작해 봅시다. 여러분이 자신의 Java 프로젝트를 진행하고 있다고 상상해 보세요. 모든 게 잘 돌아가다가도 “실험”의 순간이 오면, 뭔가를 바꾸고 싶지만 동작하는 버전을 망가뜨릴까 봐 걱정됩니다. 어떻게 하시나요? 물론, 프로젝트를 복사하죠!
결국 디스크에는 이런 걸작들이 생깁니다:
MyProject/
├── Main.java
├── Main_backup.java
├── Main_final.java
├── Main_final2.java
├── Main_tochno_final.java
├── Main_tochno_tochno_final.java
익숙하신가요? 이제 여기에 친구가 합류했다고 상상해 보세요. 그 친구도 파일 복사를 좋아하지만, 자신만의 방식으로 합니다. 그러면 최신이며 정상 동작하는 버전이 무엇인지 어떻게 알 수 있을까요? 누가 무엇을 바꿨는지 어떻게 파악할까요? 실험이 실패했을 때 어떻게 되돌릴 수 있을까요?
버전 관리가 없다면:
- 동작하는 코드를 잃어버리거나 뒤섞기 쉽습니다.
- 이전 버전으로 ‘롤백’하기가 불가능합니다.
- 둘, 셋이 함께 작업하기가 어렵습니다.
- 혼란스러워지고 실험이 두려워집니다.
바로 이런 문제를 버전 관리 시스템 — Git 같은 — 이 해결해 줍니다.
2. 개발자에게 Git이 필요한 이유
Git은 강력한 버전 관리 시스템으로, 소프트웨어를 개발하는 동안 소스 코드의 변경 사항을 추적하는 데 사용됩니다. 개발자는 파일의 다양한 버전을 보관하고, 여러 사람이 하나의 프로젝트에서 함께 작업하도록 조율할 수 있습니다.
Git의 핵심 개념:
저장소
저장소(또는 “repo”)는 프로젝트의 모든 기록, 즉 모든 변경 사항과 파일 버전을 보관하는 장소입니다.
커밋
commit은 프로젝트의 저장된 상태입니다. Git의 각 커밋은 프로젝트에 어떤 변경이 언제, 누구에 의해 이루어졌는지를 담습니다. 커밋은 프로젝트의 역사(히스토리)를 만들며, 과거 어느 시점으로든 돌아갈 수 있게 해줍니다.
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
각 커밋은 이전 커밋을 잇는 프로젝트의 “스냅샷”으로, 변화의 연속적인 이력을 형성합니다.
브랜치
branch는 독립적인 개발 라인입니다. 기본적으로 Git은 main 브랜치를 만듭니다. 새로운 기능 개발이나 버그 수정용으로 새 브랜치를 만든 다음, 작업이 끝나면 다시 기본 브랜치로 병합할 수 있습니다.
gitGraph
commit id: "1"
commit id: "2"
branch develop
commit id: "3"
commit id: "4"
commit id: "5"
checkout main
commit id: "6"
commit id: "7"
merge develop
commit id: "8"
commit id: "9"
기본 브랜치 main에서 병렬 개발을 위해 develop 브랜치를 ‘갈라’ 만듭니다. 작업을 마치면 develop의 변경 사항을 다시 main에 병합합니다.
3. Git의 기본 명령어(보닛 아래에서 일어나는 일)
아래는 터미널에서 Git을 다룰 때 사용하는 기본 명령어 목록입니다. 모든 작업의 기저에 어떤 명령이 있는지 이해하는 것이 중요합니다. 하지만 우리는 GUI 접근법을 따르며, IntelliJ IDEA의 편리한 그래픽 인터페이스로 이 모든 작업을 수행하는 방법을 익힐 것입니다. 이 명령어들은 ‘보닛 아래’에서 벌어지는 일이라고 생각하세요.
| 명령어 | 설명 |
|---|---|
git init |
현재 디렉터리에 새 Git 저장소를 초기화합니다. |
git clone |
URL에서 저장소를 새 디렉터리로 클론합니다. |
git add |
다음 커밋을 위해 파일을 인덱스(Staging)에 추가합니다. |
git commit |
준비된 변경 사항을 저장소에 기록합니다. |
git push |
로컬 저장소의 변경 사항을 원격으로 전송합니다. |
git pull |
현재 브랜치를 원격 저장소의 최신 버전으로 업데이트합니다. |
git branch |
브랜치를 표시, 생성 또는 삭제합니다. |
git merge |
지정한 브랜치의 변경 사항을 현재 브랜치로 병합합니다. |
이 명령어들은 Git에서 코드 변경, 브랜치, 병합을 관리하는 기본 도구로, 어떤 규모의 프로젝트에도 적용됩니다.
sequenceDiagram
participant 작업 디렉터리
participant 스테이징 영역 (Staging)
participant 로컬 저장소
participant 원격 저장소
작업 디렉터리 ->> 스테이징 영역 (Staging): git add (준비)
스테이징 영역 (Staging) ->> 로컬 저장소: git commit (로컬에 저장)
로컬 저장소 ->> 원격 저장소: git push (원격으로 전송)
원격 저장소 ->> 작업 디렉터리: git pull (업데이트 내려받기)
4. 코드가 저장되는 세 가지 위치
버전 관리 시스템을 사용하면, 여러분의 코드는 크게 세 곳에 저장됩니다:
1. 원격 저장소
원격 저장소는 보통 GitHub, GitLab, Bitbucket 같은 서비스에 호스팅되는, 코드의 중앙 저장소입니다. 공동 작업의 기반이 되며, 빌드·테스트·배포 같은 자동화의 통합 지점 역할을 합니다.
2. 로컬 저장소
로컬 저장소는 여러분의 컴퓨터에 있는 개인 복제본입니다. 여기서 인터넷 연결 없이도 Git의 모든 작업(커밋, 브랜치, 병합)을 수행할 수 있습니다.
3. 작업 디렉터리
작업 디렉터리는 현재 작업 중인 프로젝트의 실제 파일들이 있는 곳입니다. 이곳에서 파일을 보고 수정하며, 새 기능을 추가하거나 버그를 고칩니다.
이 세 구성 요소가 함께 강력한 소스 코드 관리 인프라를 제공하여, 개발자가 프로젝트 이력을 관리하고 협업할 수 있게 해줍니다.
5. GitHub — 여러분의 포트폴리오
GitHub는 소스 코드 호스팅을 위한 선도적인 웹 플랫폼으로, Git 버전 관리 시스템을 사용합니다. 2008년에 설립되어 전 세계 개발자들의 핵심 도구 중 하나로 빠르게 자리 잡았습니다.
GitHub에서는 사용자가 프로젝트를 관리할 수 있는 저장소를 만들고, 코드 변경을 제어·추적하며, 다른 개발자와 협업할 수 있습니다. 현대 개발자에게 GitHub 프로필은 잠재적 고용주에게 보여줄 수 있는 포트폴리오의 중요한 일부입니다.
6. GitHub에서 첫 저장소 만들기
1단계. https://github.com에 접속해 회원가입합니다.
2단계. 새 저장소를 만들려면 New repository 버튼을 클릭합니다.
3단계. 저장소의 매개변수를 설정합니다:
- 저장소 이름: 의미 있는 이름을 정하세요.
- 공개 또는 비공개: 학습용 프로젝트라면 다른 사람이 볼 수 있도록 “Public”을 권장합니다.
- Add a README file: 이 옵션은 반드시 선택하세요. README는 프로젝트의 “얼굴”입니다.
- Add .gitignore: 드롭다운을 눌러 사용하는 언어에 맞는 템플릿을 선택하세요.
- Choose a license: 건너뛰어도 됩니다.
Create repository를 클릭합니다.
4단계. 축하합니다. 첫 원격 저장소가 생성되었습니다!
7. Git 설치 및 설정
Git의 기본은 콘솔 명령으로도 배울 수 있지만(영상에서 보여줌), 일상적인 업무에서는 99%의 개발자가 IDE에 내장된 편리한 도구를 사용합니다. 우리의 목표는 여러분이 전문가처럼 작업하도록 돕는 것입니다.
JetBrains의 모든 최신 IDE에서 Git 인터페이스는 거의 동일합니다 — Java/Kotlin용 IntelliJ IDEA, C#용 Rider, Python용 PyCharm 등. 한 환경에서 Git을 익히면 다른 환경에서도 쉽게 적용할 수 있다는 뜻입니다. 그래서 범용 예제로 IntelliJ IDEA를 사용할 것입니다. 여기서 보게 될 모든 내용은 여러분이 즐겨 쓰는 IDE에서도 거의 똑같이 보이고 작동합니다.
여러분의 컴퓨터에서 Git을 사용하려면 먼저 Git을 설치해야 합니다. IntelliJ IDEA를 사용한다면, 시스템에서 Git을 찾을 수 없을 때 자동 설치를 제안할 가능성이 큽니다. 이 제안을 수락하는 것을 권장합니다 — 가장 쉬운 방법입니다.
현재 프로젝트를 File > Close Project로 닫은 뒤, Clone Repository를 클릭하세요.
수동으로 설치하고 싶다면 공식 사이트를 이용하세요: https://git-scm.com/downloads.
8. 짧은 역사: main vs master
과거 Git의 기본 브랜치 이름은 master였습니다. 그러나 2020년에 개발자 커뮤니티와 GitHub을 포함한 주요 플랫폼들이 보다 중립적인 용어인 main으로 전환했습니다.
이는 알아둘 가치가 있습니다. 오래된 글이나 프로젝트에서는 여전히 master 브랜치 언급을 볼 수 있기 때문입니다. 우리의 강의와 최신 프로젝트에서는 기본 브랜치가 항상 main입니다.
main으로의 전환에 대해 더 알아보려면 다음 링크를 참고하세요:
GO TO FULL VERSION