Git 소개: 왜 버전 컨트롤이 필요한가

1. 버전 관리가 없을 때의 문제: 파일을 그냥 복사하는 게 왜 안 좋은가

실제 상황부터 시작해봅시다. C# 프로젝트를 작업 중이라고 상상해보세요. 모든 게 잘 가다가 "실험"할 시점이 오면 문제가 생깁니다. 뭔가 바꿔보고 싶은데, 작업 중인 버전이 망가질까봐 겁이 나죠. 어떻게 할까요? 당연히 프로젝트를 복사합니다!

결국 디스크에는 이런 걸작들이 생깁니다:

MyProject/
├── Main.cs
├── Main_backup.cs
├── Main_final.cs
├── Main_final2.cs
├── Main_точно_финал.cs
├── Main_точно_точно_финал.cs

익숙하죠? 이제 친구가 프로젝트에 합류했다고 해봅시다. 그도 파일 복사를 좋아하는데 자기 방식대로 합니다. 어디가 최신이고 작동하는 버전인지 어떻게 알겠어요? 누가 무엇을 바꿨는지 어떻게 알 수 있죠? 실험이 실패했을 때 어떻게 되돌리죠?

버전 관리가 없으면:

• 작업 코드를 잃어버리거나 섞어버리기 쉽다.
• 이전 버전으로 "되돌리기"가 불가능하다.
• 둘 이상이 함께 작업하기 어렵다.
• 혼돈과 실험에 대한 두려움이 생긴다.

바로 이런 문제들을 해결해주는 것이 버전 관리 시스템입니다 — 예를 들어 Git.

2. 개발자에게 Git가 왜 필요한가?

Git — 강력한 버전 관리 시스템으로, 소프트웨어 개발 중 소스 코드의 변경을 추적하는 데 사용됩니다. 개발자는 파일의 여러 버전을 저장하고 여러 사람이 같은 프로젝트에서 협업할 수 있습니다.

Git의 주요 개념:

레포지토리

레포지토리(또는 "repo")는 모든 변경사항과 파일 버전을 포함해 프로젝트의 전체 이력이 저장되는 장소입니다.

커밋

commit — 프로젝트의 저장된 상태예요. 각 커밋은 프로젝트에 어떤 변경이 있었는지, 누가 언제 했는지에 대한 정보를 포함합니다. 커밋은 프로젝트의 히스토리를 만들며 언제든 이전 버전으로 돌아갈 수 있게 해줍니다.

        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의 편한 그래픽 인터페이스로 이 모든 작업을 수행하는 법을 배울 거예요. 이 명령어들을 시스템의 "하부 구조"로 이해하세요.

이 명령어들은 어떤 규모의 프로젝트에서든 코드 변경, 브랜치 및 병합을 관리하는 기본 도구들입니다.

        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. 레포지토리 설정을 지정하세요:

1. 레포지토리 이름: 의미 있는 이름을 지으세요.
2. Public 또는 Private: 학습용 프로젝트라면 다른 사람이 볼 수 있게 "Public"을 선택하는 게 좋아요.
3. Add a README file: 이 체크박스는 꼭 선택하세요. README는 프로젝트의 "얼굴"입니다.
4. Add .gitignore: 드롭다운에서 사용 언어에 맞는 템플릿을 선택하세요.
5. Choose a license: 생략해도 됩니다.
6. 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 대 master

이전에는 Git의 기본 브랜치가 master라고 불렸습니다. 하지만 2020년에 개발자 커뮤니티와 주요 플랫폼들이 더 중립적인 용어인 main으로 전환했어요.

이 점을 아는 게 중요한데, 오래된 글이나 프로젝트에서는 아직 master가 나올 수 있습니다. 우리 강의와 최신 프로젝트에서는 기본 브랜치를 항상 main으로 사용할 거예요.

main으로의 전환에 대해 더 알고 싶다면 다음 링크를 참고하세요:

• Git Tower: Rename Master to Main
• GitHub: Renaming