Git을 처음 접하는 사람을 대상으로, Git이 무엇인지부터 GitHub에 코드를 올리고 협업하는 과정까지 하나씩 따라 해보는 글입니다.

Git이란?
GitHub란?
Git과 GitHub는 무엇이 다른가?
Git 설치하기
Git 최초 설정
Git 저장소 만들기
Git의 핵심: add와 commit
Git 상태 확인하기
커밋 기록 확인하기
브랜치란?
브랜치 생성과 이동
브랜치 병합하기
GitHub 저장소 만들기
로컬 저장소를 GitHub와 연결하기
push / pull 이해하기
clone으로 프로젝트 가져오기
Pull Request란?
실무에서 자주 사용하는 Git 흐름
.gitignore란?
자주 사용하는 명령어 정리

1. Git이란?

Git은 파일의 변경 이력을 관리하는 버전 관리 시스템(Version Control System)이다.

예를 들어 프로젝트를 진행하다 보면 이런 파일을 만들게 된다.

project_최종
project_진짜최종
project_진짜진짜최종
project_최종2

Git을 사용하면 이런 방식으로 파일을 복사하지 않아도 된다.

Git은 변경 내용을 커밋(commit)이라는 단위로 기록한다.

첫 번째 커밋
      ↓
로그인 기능 추가
      ↓
회원가입 기능 추가
      ↓
버그 수정

필요하면 과거 시점의 코드도 확인할 수 있다.

즉 Git의 핵심 목적은 다음과 같다.

변경 이력을 남긴다.
누가 어떤 코드를 수정했는지 확인한다.
과거 버전으로 돌아갈 수 있다.
여러 개발자가 같은 프로젝트를 함께 개발할 수 있다.

2. GitHub란?

GitHub는 Git 저장소를 인터넷에 보관하고 공유할 수 있는 서비스다.

Git 자체는 내 컴퓨터에서도 사용할 수 있다.

내 컴퓨터
└── 프로젝트
    └── .git

하지만 내 컴퓨터가 고장 나거나 다른 개발자와 코드를 공유해야 한다면 원격 저장소가 필요하다.

그 역할을 GitHub가 해준다.

GitHub 외에도 GitLab, Bitbucket 등 Git 저장소를 호스팅하는 서비스가 있다.

3. Git과 GitHub는 무엇이 다른가?

둘을 처음 배우면 가장 많이 헷갈리는 부분이다.

간단하게 생각하면 다음과 같다.

구분	Git	GitHub
정체	버전 관리 프로그램	Git 저장소 호스팅 서비스
위치	주로 내 컴퓨터	인터넷 서버
주요 역할	변경 이력 관리	코드 공유, 협업, 리뷰
대표 명령	`git add`, `git commit`	`git push`, PR 등으로 연동

핵심은 이것이다.

Git으로 버전을 관리하고, GitHub에 그 저장소를 올려 공유한다.

4. Git 설치하기

먼저 Git이 설치되어 있는지 확인한다.

git --version

예를 들어 다음과 같이 나오면 설치되어 있는 것이다.

git version 2.x.x

macOS

Homebrew를 사용하는 경우:

brew install git

macOS에서는 Xcode Command Line Tools 설치 과정에서 Git이 함께 제공되는 경우도 있다.

Ubuntu / Debian

sudo apt update
sudo apt install git

Windows

Git 공식 사이트에서 Git for Windows를 설치하면 된다.

설치 후 다시 확인한다.

git --version

5. Git 최초 설정

Git은 커밋을 만들 때 작성자가 누구인지 기록한다.

처음 설치했다면 이름과 이메일을 설정한다.

git config --global user.name "Hong Gil Dong"
git config --global user.email "hong@example.com"

설정값 확인:

git config --global --list

GitHub의 커밋 기록과 연결하려면 GitHub 계정에 등록한 이메일을 사용하는 것이 편하다.

6. Git 저장소 만들기

간단한 프로젝트를 하나 만들어보자.

mkdir git-study
cd git-study

파일 하나를 만든다.

echo "# Git Study" > README.md

현재 디렉터리를 Git 저장소로 만든다.

git init

실행하면 현재 디렉터리에 숨김 디렉터리인 .git이 생성된다.

git-study/
├── .git/
└── README.md

.git 안에 커밋, 브랜치 등 Git이 사용하는 정보가 저장된다.

따라서 .git 디렉터리를 삭제하면 해당 디렉터리는 더 이상 기존 Git 저장소로 동작하지 않는다.

7. Git의 핵심: add와 commit

Git을 처음 배우면서 가장 중요한 개념이다.

Git에서는 보통 다음 순서로 작업한다.

파일 수정
   ↓
git add
   ↓
Staging Area
   ↓
git commit
   ↓
Repository

7.1 파일 수정하기

README.md를 수정해보자.

# Git Study

Git을 공부하는 저장소입니다.

7.2 git add

커밋할 변경사항을 선택한다.

git add README.md

모든 변경 파일을 추가하려면:

git add .

git add는 GitHub에 파일을 업로드하는 명령어가 아니다.

정확히는:

다음 커밋에 포함할 변경사항을 Staging Area에 올리는 명령어다.

7.3 git commit

이제 변경사항을 하나의 버전으로 기록한다.

git commit -m "README 작성"

-m 뒤에는 커밋 메시지를 작성한다.

예:

git commit -m "회원가입 API 추가"
git commit -m "로그인 오류 수정"
git commit -m "README 수정"

커밋 메시지는 무엇을 변경했는지 알 수 있도록 작성하는 것이 좋다.

8. Git 상태 확인하기

Git을 사용할 때 가장 자주 입력하는 명령어 중 하나다.

git status

현재 파일이 어떤 상태인지 보여준다.

예를 들어:

Untracked files:
  README.md

Git이 아직 추적하지 않는 새 파일이 있다는 뜻이다.

git add README.md 후에는:

Changes to be committed:
  new file: README.md

커밋할 준비가 된 상태다.

Git을 사용하다 헷갈린다면 우선 다음 명령어를 입력해보자.

git status

9. 커밋 기록 확인하기

커밋 기록은 다음 명령어로 확인한다.

git log

간단하게 보고 싶다면:

git log --oneline

예:

fc84a21 로그인 기능 추가
0a89fd2 README 작성

앞의 문자열은 커밋을 식별하는 커밋 해시(commit hash)다.

10. 브랜치란?

브랜치(branch)는 기존 코드에서 독립된 작업 흐름을 만드는 기능이다.

예를 들어 현재 정상적으로 서비스 중인 코드가 main에 있다고 하자.

로그인 기능을 개발한다고 해서 main을 바로 계속 수정하면, 개발 중인 코드가 안정적인 코드에 섞일 수 있다.

그래서 별도의 브랜치를 만든다.

main
 │
 ├──── feature/login
 │        │
 │        ├─ 로그인 API 개발
 │        └─ 테스트
 │
 └──────── merge

브랜치를 사용하면 여러 기능을 독립적으로 개발할 수 있다.

11. 브랜치 생성과 이동

현재 브랜치를 확인한다.

git branch

새로운 브랜치를 만든다.

git branch feature/login

해당 브랜치로 이동한다.

git switch feature/login

생성과 이동을 한 번에 하려면:

git switch -c feature/login

과거에는 다음 명령어도 많이 사용했다.

git checkout -b feature/login

지금도 정상적으로 사용할 수 있다.

12. 브랜치 병합하기

feature/login에서 작업을 완료했다고 하자.

먼저 main으로 이동한다.

git switch main

그리고 병합한다.

git merge feature/login

결과적으로 feature/login의 변경사항이 main에 합쳐진다.

작업이 끝난 브랜치가 필요 없다면 삭제할 수 있다.

git branch -d feature/login

13. GitHub 저장소 만들기

이제 로컬 프로젝트를 GitHub에 올려보자.

GitHub에서:

우측 상단 + 버튼
→ New repository

Repository name을 입력한다.

예:

git-study

그리고 저장소를 생성한다.

기존 로컬 프로젝트를 올리는 실습이라면 GitHub에서 README, .gitignore, License를 미리 생성하지 않고 빈 저장소로 만드는 편이 단순하다.

14. 로컬 저장소를 GitHub와 연결하기

현재까지 구조는 다음과 같다.

내 컴퓨터

git-study
└── .git

GitHub 저장소를 만들었다면 로컬 저장소에 원격 저장소 주소를 등록한다.

git remote add origin https://github.com/USERNAME/git-study.git

등록된 원격 저장소 확인:

git remote -v

예:

origin  https://github.com/USERNAME/git-study.git (fetch)
origin  https://github.com/USERNAME/git-study.git (push)

여기서 origin은 원격 저장소에 붙인 별칭이다.

반드시 origin이어야 하는 것은 아니지만 관례적으로 가장 많이 사용한다.

15. push / pull 이해하기

GitHub를 사용하면서 매우 자주 등장하는 명령어다.

push

내 컴퓨터의 커밋을 원격 저장소에 업로드한다.

Local
  │
  │ push
  ▼
GitHub

처음 main 브랜치를 올릴 때:

git push -u origin main

이후에는 보통:

git push

만으로도 가능하다.

pull

원격 저장소의 변경사항을 가져와 현재 브랜치에 반영한다.

GitHub
  │
  │ pull
  ▼
Local

git pull

여러 사람이 함께 작업하는 저장소에서는 다른 개발자가 먼저 코드를 올렸을 수 있으므로 원격 변경사항을 확인하고 가져오는 과정이 중요하다.

16. clone으로 프로젝트 가져오기

이미 GitHub에 존재하는 프로젝트를 처음 내 컴퓨터로 가져오고 싶다면 clone을 사용한다.

git clone https://github.com/USERNAME/project.git

그러면 대략 다음과 같이 내려받아진다.

project/
├── .git/
├── src/
├── README.md
└── ...

clone은 단순히 현재 파일 몇 개만 복사하는 것이 아니라 Git 저장소의 이력과 관련 정보까지 포함한 로컬 복사본을 만드는 명령이다.

17. Pull Request란?

실무에서는 작업한 코드를 바로 main에 합치기보다 Pull Request(PR)를 이용하는 경우가 많다.

예를 들어 로그인 기능을 개발한다고 하자.

git switch -c feature/login

코드를 수정하고:

git add .

커밋한다.

git commit -m "로그인 기능 추가"

GitHub에 브랜치를 올린다.

git push -u origin feature/login

그 다음 GitHub에서 Pull Request를 만든다.

feature/login
       │
       │ Pull Request
       ▼
      main

Pull Request에서는 다음과 같은 작업을 할 수 있다.

어떤 코드가 변경되었는지 확인
다른 개발자가 코드 리뷰
의견과 수정 요청 작성
테스트 결과 확인
승인 후 merge

즉 PR은 단순히 코드를 합치는 버튼이라기보다:

내가 작업한 변경사항을 main에 합쳐도 되는지 팀에게 제안하고 검토하는 과정

이라고 이해하면 쉽다.

18. 실무에서 자주 사용하는 Git 흐름

팀마다 방식은 다르지만 초보자가 이해하기 좋은 기본 흐름은 다음과 같다.

1. 최신 코드 가져오기

git switch main
git pull

        ↓

2. 작업 브랜치 생성

git switch -c feature/login

        ↓

3. 코드 수정

        ↓

4. 변경사항 확인

git status
git diff

        ↓

5. Staging

git add .

        ↓

6. Commit

git commit -m "로그인 기능 추가"

        ↓

7. GitHub에 Push

git push -u origin feature/login

        ↓

8. Pull Request 생성

        ↓

9. 코드 리뷰

        ↓

10. main에 Merge

이 흐름에 익숙해지면 기본적인 Git/GitHub 협업을 이해하는 데 큰 도움이 된다.

19. .gitignore란?

프로젝트에는 Git에 올리면 안 되거나 굳이 관리할 필요가 없는 파일이 존재한다.

예:

node_modules/
build/
.idea/
.env
*.log

이런 파일은 .gitignore에 등록한다.

예를 들어 Node.js 프로젝트라면:

node_modules/
.env
*.log

Java 프로젝트라면:

build/
target/
*.class

특히 API Key, 비밀번호, 인증 토큰 등이 담긴 파일은 Git 저장소에 커밋하지 않도록 주의해야 한다.

20. 자주 사용하는 명령어 정리

명령어	의미
`git init`	현재 디렉터리를 Git 저장소로 생성
`git status`	현재 변경 상태 확인
`git add 파일명`	특정 변경사항을 staging
`git add .`	현재 경로 아래 변경사항을 staging
`git commit -m "메시지"`	커밋 생성
`git log`	커밋 기록 확인
`git log --oneline`	커밋 기록 간단히 확인
`git diff`	변경 내용 확인
`git branch`	브랜치 목록 확인
`git switch 브랜치`	브랜치 이동
`git switch -c 브랜치`	새 브랜치 생성 후 이동
`git merge 브랜치`	브랜치 병합
`git remote -v`	원격 저장소 확인
`git push`	원격 저장소로 커밋 전송
`git pull`	원격 변경사항 가져와 반영
`git clone URL`	원격 저장소 복제

마지막으로 정리

Git을 처음 배울 때 모든 명령어를 외우려고 하면 어렵다.

처음에는 아래 흐름만 확실히 이해하면 된다.

파일 수정

   ↓

git add

   ↓

git commit

   ↓

git push

   ↓

GitHub

협업에서는 여기에 브랜치와 Pull Request가 추가된다.

main 최신화
   ↓
branch 생성
   ↓
코드 수정
   ↓
add
   ↓
commit
   ↓
push
   ↓
Pull Request
   ↓
review
   ↓
merge

그리고 헷갈릴 때 가장 먼저 사용할 명령어는 이것이다.

git status

Git은 명령어 자체보다 Working Directory → Staging Area → Commit → Remote Repository라는 흐름을 이해하는 것이 중요하다.

이 구조가 머릿속에 잡히면 이후 rebase, reset, revert, stash, cherry-pick, worktree 같은 기능도 훨씬 쉽게 이해할 수 있다.

참고 자료

Git 공식 사이트: https://git-scm.com/
Pro Git: https://git-scm.com/book/
GitHub Docs: https://docs.github.com/
GitHub 저장소 생성 문서: https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-new-repository
GitHub Clone 문서: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
GitHub Pull Request 문서: https://docs.github.com/en/pull-requests

dev-setung

Git/GitHub 기초부터 시작하기 — 완전 초보자를 위한 튜토리얼

목차