CS: Git, Github

hyeppy·2025년 8월 10일

CS

목록 보기

1/11

버전 관리 시스템 Git, Github

Git 저장소의 기본 구조

Git 저장소를 초기화하면(git init) .git 폴더가 생성되며, 이 안에 모든 Git 데이터가 저장됨

.git/
 ├─ HEAD
 ├─ config
 ├─ objects/      ← Git 객체 데이터 저장소
 ├─ refs/         ← 브랜치/태그 참조
 ├─ hooks/
 └─ ...

Git의 핵심 구성 요소

Git 객체 (Object)
- Blob (파일 내용), Tree (디렉토리 구조와 파일(Blob) 참조), Commit (스냅샷(Tree) + 메타데이터), Tag (특정 커밋에 이름)
- 모든 객체는 SHA-1 해시값(40자리)로 식별
스냅샷 방식
- SVN, CVS 같은 전통적 VCS는 변경 내용(Data)만 저장
- Git은 매번 전체 파일 구조(Tree)의 스냅샷을 저장
인덱스(Index, Staging Area)
- 작업 디렉토리(Working Directory) ↔ 인덱스 ↔ 저장소(Repository) 구조
- git add 시 인덱스에 기록 → git commit 시 인덱스 내용이 Commit 객체로 변환

Git 내부 동작 흐름

작업 디렉토리: 실제 수정하는 파일이 위치해 있는 디렉토리
git add: 인덱스(Staging Area)에 변경 사항 기록
git commit: 인덱스 스냅샷을 객체 데이터베이스에 저장
git push: 브랜치 참조(refs/head/브랜치명)가 새 커밋을 가리키도록 이동

Git의 핵심 장점

빠른 버전 이동: 참조만 변경하면 바로 이동 가능
데이터 무결성: SHA-1 해시 기반으로 데이터 변조 방지
공간 효율성: 변경 없는 파일은 해시 재활용
분산 구조: 모든 개발자가 전체 히스토리 보관 가능

bash 쉘 기본 명령어

명령어	설명	예시/주의사항
`ls`	현재 디렉토리의 파일/폴더 목록 조회	`ls` → 일반 목록, `ls -l` → 상세 목록
`ls -al`	숨김파일(`.`으로 시작) 포함 모든 파일 상세 목록 조회	Git 저장소의 `.git` 폴더 확인 시 유용
`clear`	터미널 화면 클리어	스크롤은 남아있음, 새로 시작 아님
`cd <경로>`	디렉토리 이동	`cd ..` → 상위 폴더, `cd ~` → 홈 디렉토리
`mkdir -p a/b/c`	중간 경로 포함 폴더 생성	`-p` 없으면 중간 폴더 없을 시 에러 발생
`rm -rf a/b/c`	폴더와 그 안의 모든 파일 강제 삭제	⚠ 매우 위험: 오타 시 데이터 영구 삭제
`touch a b c`	여러 개의 빈 파일 생성	기존 파일이 있으면 수정 시간만 변경
`pwd`	현재 디렉토리의 절대 경로 표시	스크립트 작성 시 현재 위치 확인 용도
`Shift + Insert`	터미널에 붙여넣기	일부 터미널에서는 `Ctrl + Shift + V`
`Ctrl + Insert`	터미널에서 복사	일부 터미널에서는 `Ctrl + Shift + C`

로컬 저장소 (Local Repository)

소스 코드를 저장하는 폴더
.git 폴더가 있는 폴더 → 소스코드의 변경 이력이 저장되는 장소
로컬 컴퓨터(= 개인 컴퓨터)에만 존재하는 저장소

로컬 저장소 생성 3가지 방법

빈 디렉토리에서 새 저장소 생성
- 작업 폴더에서 처음부터 Git을 시작할 때 사용
```
# 1. 프로젝트 폴더 생성
mkdir my-project
cd my-project

# 2. Git 초기화
git init
```
  ⇒ 현재 디렉토리에 .git 폴더 생성
  ⇒ 기본 브랜치: main

기존 폴더를 Git 저장소로 변환

이미 파일이 있는 폴더에서 Git을 적용할 때 사용

cd existing-folder
git init  # .git 폴더 생성
git add .  # 현재 폴더의 모든 파일을 스테이징
git commit -m "Initial commit" # 첫 번째 커밋 생성

원격 저장소를 복제(Clone)하여 로컬 저장소 생성
- Github, GitLab, Bitbucket 등에서 내려받을 때 사용
```
git clone https://github.com/[username]/[repo].git
```
  ⇒ repo 라는 폴더가 생성되고, .git 폴더와 모든 파일 포함
  ⇒ 원격 저장소(origin)와 연결된 상태

원격 저장소에 권한이 없으면 Github에서 fork ⇒ 밑 내용 참고

git init 을 이미 .git 폴더가 있는 곳에서 실행하면, 새로운 저장소가 아니라 기존 저장소 초기화가 될 수 있으니 주의

새로 만든 저장소는 원격(remote)과 연결되지 않음
= 내 컴퓨터에만 .git 폴더가 생기고, GitHub와 같은 외부 저장소와는 아무 연결 정보가 없는 상태
⇒ git remote add origin <url> 사용

로컬 저장소 삭제

로컬 저장소란, .git 폴더가 있는 디렉토리 전체를 의미

프로젝트 전체 삭제

저장소와 그 안의 파일, 커밋 기록까지 모두 지우는 방법

# macOS / Linux
rm -rf my-project

# Windows (PowerShell)
Remove-Item -Recurse -Force my-project

Git 기능만 제거 (파일 유지)
- 프로젝트 파일은 유지하되, Git 버전 관리 기능만 제거하려면 .git 폴더만 삭제
```
# macOS / Linux
rm -rf .git

# Windows (PowerShell)
Remove-Item -Recurse -Force .git
```

삭제 시 복구 불가, 정말 삭제해도 되는지 확인 후 실행

내 폴더가 Git 저장소인지 확인하는 방법?

macOS / Linux → ls -a

windows → dir /a

⇒ .git이 있으면 Git 저장소

Git 명령어 & 기능

분류	명령어	설명
브랜치 관리	`git branch`, `git switch`, `git checkout -b`	생성/전환
원격	`git remote -v`, `git fetch`, `git pull`, `git push`	원격 저장소 관리
변경 비교	`git diff`, `git stash`	변경 확인/임시 저장
태그	`git tag`, `git push origin <tag>`	버전 태그
히스토리	`git log`, `git show`, `git blame`, `git shortlog`	기록 조회
복구	`git restore`, `git reset`, `git revert`	상태 되돌리기
설정	`git config`	사용자 정보, 편집기 설정
탐험	`git reflog`	HEAD 이동 기록 보기

git stash → 작업 중인데 브랜치 변경해야 할 때 필수

git reflog → 실수로 브랜치 삭제하거나 reset한 경우 마지막 희망

git diff → 커밋 전 변경 내용 꼭 확인하는 습관

git blame → 버그 추적에 매우 유용

git rebase → 깔끔한 히스토리 만들 때 사용하지만 충돌 관리 주의

유저 정보 등록

git config user.name "nickname"

git config user.email "github 이메일"

Remote

원격 저장소(Remote repository)를 관리하는 명령어
로컬 저장소가 어떤 원격 저장소와 연결되어 있는지 확인, 추가, 변경, 삭제

원격 저장소는 Github, Gitlab, Bitbucket 같은 서버에 위치

# 원격 저장소 목록 확인
git remote -v
# 결과
origin  https://github.com/[username]/[project].git (fetch)
origin  https://github.com/[username]/[project].git (push)
# origin: 원격 저장소의 별칭(alias)
# (fetch): 가져올 때 사용되는 URL
# (push): 푸시할 때 사용되는 URL

# 원격 저장소 추가
git remote add origin https://github.com/[username]/[project].git

# 원격 저장소 URL 변경
git remote set-url origin https://github.com/[username]/[new-project].git

# 원격 저장소 삭제
git remote remove origin

# 원격 저장소 이름 변경
git remote rename origin upstream

origin: 내가 push/pull 하는 기본 원격 저장소
upstream: 원본 저장소 (Fork한 경우 원작자의 저장소)

Push

push는 로컬 저장소의 커밋을 원격 저장소로 업로드하는 과정

# 1. 파일 수정 후 스테이징
git add .

# 2. 커밋 생성
git commit -m "메시지"

# 3. 원격 저장소로 푸시
git push origin main

# 3-1. 첫 푸시 때 아래 명령어 입력 시, 이후에는 git push만 입력해도 됨
git push -u origin main

origin: 원격 저장소의 이름 (기본 별칭)
main: push 할 브랜치 이름

Status

작업 디렉토리와 스테이징 상태를 확인하는 명령어
→ 변경 사항, 추적 여부, 현재 브랜치 등을 알려 줌

git status

# 결과
On branch main
Your branch is up to date with 'origin/main'.

# 수정했지만 git add 안 한 파일
Changes not staged for commit:
  modified:   app.js

# git이 추적하지 않는 새 파일
Untracked files:
  README.md

# git add로 스테이징한 파일
Changes to be committed:
  new file:   index.html

git status -s

Branch (브랜치)
- Git에서 커밋의 흐름을 분리해 관리하는 기능
  ⇒ 작업 줄기를 따로 만들어서 실험, 기능 개발, 버그 수정 등을 독립적으로 진행
- 단순히 마지막 커밋을 가리키는 포인터일 뿐이라, 생성/전환이 매우 빠르고 가벼움
- 기본 구조
  - Git 초기화 후 기본적으로 main(이전에는 master) **브랜치가 생성
  - 브랜치는 커밋 ID**를 가리키고, 새 커밋이 만들어질 때 포인터가 앞으로 이동
```
 main → C1 → C2
 dev1  → C1 → C2 → C3
 dev2  → C1 → C2 → C3 → C4
```
  → 브랜치는 다른 브랜치의 변경 사항에 영향을 받지 않고 각각 다른 커밋을 쌓을 수 있음
```
# 브랜치 생성
git branch dev

# 브랜치 전환
git switch dev
# 또는 구버전
git checkout dev

#브랜치 생성과 동시에 전환
git switch -c dev
# 또는
git checkout -b dev

# 브랜치 목록 보기
git branch
# -a 옵션: 로컬 + 원격 모두 보기

# 브랜치 삭제
git branch -d dev    # 병합된 브랜치 삭제
git branch -D dev    # 강제 삭제(미병합 포함)

# 브랜치 병합
# main으로 이동
git switch main
# dev 브랜치 병합
git merge dev
```
- 브랜치 장점
  - 실험적인 작업을 안전하게 수행 가능
  - 협업 시 작업 충돌 최소화
  - 코드 리뷰(Pull Request) 기반 개발 가능
  - 필요한 시점에만 main에 병합 가능

Checkout

git checkout은 브랜치를 전환하거나, 특정 커밋 시점으로 이동하는 명령어

 # 브랜치 전환: 현재 브랜치에서 입력한 브랜치로 전환
 git checkout dev
 
 # 새 브랜치 생성 + 전환: feature/login 브랜치를 만들고 바로 이동
 git checkout -b feature/login 
 
 # 특정 커밋 시점으로 이동 (detached Head 상태)
 git checkout [원하는 시점]

최신 Git 버전에서는 git switch로 브랜치 이동, git restore로 파일 복구 권장

브랜치 전환

# main 브랜치로 전환
git switch main

# feature/login 브랜치 생성 후 이동
git switch -c feature/login

파일 복구

 # 현재 브랜치의 최신 커밋 상태로 되돌림
 git restore 파일명
 # = git checkout --파일명
 
 # git add 한 파일을 스테이징 해제
 git restore --staged 파일명
 
 # abc1234 커밋 시점의 파일로 되돌림
 git restore --source abc1234 파일명

작업	기존 방식 (`checkout`)	최신 방식 (권장)
브랜치 전환	`git checkout main`	`git switch main`
브랜치 생성+전환	`git checkout -b new`	`git switch -c new`
파일 변경 취소	`git checkout -- file`	`git restore file`
스테이징 해제	`git reset file`	`git restore --staged file`

Merge (병합) & Pull Request
- 단순 merge
```
# main 브랜치로 이동
git checkout main

# dev 브랜치를 main에 병합
git merge dev
```
  - main 브랜치에 dev 브랜치 변경 사항이 합쳐짐
    ⇒ 충돌 발생 시 수동으로 해결 후 커밋
- Pull Request (PR) 방식
  1. 새로운 브랜치 생성 → 작업 → 커밋 → 원격 저장소에 push
  2. 웹에서 Pull Request 생성
  3. 팀원이 코드 리뷰 후 승인
  4. 서버에서 자동 merge
  5. 병합이 완료된 브랜치의 경우 삭제 가능 (선택)
  - 장점: 코드 리뷰, CI/CD 검사, 충돌 방지
- pull (가져오기 + 병합)
```
git pull origin main
# 또는
git fetch origin
git merge origin/main
```
  - 원격 저장소의 main 변경 사항을 fetch + merge
  - 협업 시, 푸시 전에 반드시 pull 해서 충돌 여부 확인하는 것이 좋음

.gitignore

Git에서 추적하지 않을 파일/폴더를 지정

공통적으로 무시하는 파일/폴더

종류	예시	이유
빌드 결과물	`bin/`, `dist/`, `build/`	소스 코드로부터 다시 만들 수 있음
의존성 폴더	`node_modules/`, `vendor/`	패키지 매니저(NPM, Maven 등)로 설치 가능
로그 파일	`*.log`	실행 시마다 생성되며 버전 관리 불필요
환경 설정 파일	`.env`, `config/*.yml`	API 키, 비밀번호 등 민감 정보 포함
OS 자동 생성 파일	`.DS_Store`(Mac), `Thumbs.db`(Windows)	운영체제에서 자동 생성, 필요 없음
IDE 설정 파일	`.idea/`, `.vscode/`, `*.iml`	개발자 개인 환경 설정이므로 공유 불필요
캐시/임시 파일	`.tmp`, `.cache`, `.gradle/`	실행 속도 향상용, 버전 관리 불필요

보안에 민감한 파일/폴더

종류	예시 파일명	이유
환경 변수 파일	`.env`, `.env.local`	DB 비밀번호, API 키, 토큰 등 민감 정보 포함
인증 키 / 비밀 키	`.pem`, `.key`, `id_rsa`, `id_rsa.pub`	서버 접속용 SSH 키, 인증서
클라우드 서비스 설정	`firebase-config.json`, `aws-credentials`	AWS, GCP, Firebase 등 접속 정보
API 설정 파일	`config.js`, `secrets.yml`, `application.properties`	API endpoint 및 보안 토큰
개인 인증 관련 문서	`.p12`, `.crt`, `*.cer`	인증서, 서명 키

해당 파일에 추적하지 않은 파일/폴더명을 작성하면 됨

# 로그 파일
*.log

# node_modules 폴더
node_modules/

# 환경 설정 파일
.env

이미 Git에 추적되고 있는 파일은 .gitignore에 추가해도 무시되지 않음
→ 먼저 추적 해제 필요

 git rm --cached <파일명>

→ 민감한 정보의 경우 히스토리에서 완전히 제거해야 함

 # git filter-repo는 별도 설치가 필요함
 # 특정 파일 제거
 git filter-repo --path secrets.txt --invert-paths
 # --path: 제거할 파일 지정
 # --invert-paths: 지정된 파일만 제외한 나머지 유지
 
 # 민감 문자열 제거
 git filter-repo --replace-text replacements.txt
 
 # 폴더 전체 삭제
 git filter-repo --path node_modules --invert-paths

→ 작업 후, 히스토리가 바뀌므로 협업자는 다시 클론해야 함

 # 강제 푸시 (주의)
 git push origin --force --all
 git push origin --force --tags

log

커밋 히스토리를 조회하는 명령어

git log

# 한 줄로 간단하게
git log --oneline

# 그래프 형태로 브랜치 구조 보기
git log --oneline --graph --all --decorate

# 최근 5개만
git log -5

Fork란?

다른 사람의 원격 저장소를 내 계정으로 복사해
원본 저장소(original repository)와 연결된 내 계정의 독립적인 원격 저장소 생성
주로 오픈소스 프로젝트 기여, 원본을 건드리지 않고 실험할 때,
원본 저장소에 접근 권한이 없을 때 사용하는 용도

Fork vs Clone vs Pull

⇒ Fork 방식과 Clone의 차이 핵심은 권한
: 권한이 있으면 clone > push가 바로 가능하나, 없으면 fork 작업 필요

Fork: 다른 사람의 원격 저장소를 내 Github 계정으로 복사
→ Github(원본 레포지토리) → Github(내 고유의 레포지토리)

오픈소스 프로젝트 등의 협업 및 독립 작업을 위한 복제

원본 저장소에 직접 수정 권한이 없을 때 사용

저장소 수정 권한이 없을 경우 사용 가능

이후 PR로 기여 가능

Clone: 원격 저장소(Github)를 로컬 컴퓨터로 복사
→ Github(원본 레포지토리) → 내 PC(로컬)

작업을 로컬에서 진행하기 위해 사용

저장소 수정 권한이 있을 경우 fork 과정 없이 PR 요청 가능

레포지토리 수정 권한이 있고, 협업 중인 저장소에서 로컬 작업이 필요할 경우
git clone <레포지토리>

구분	Fork	Clone	Pull
저장 위치	원격 서버(GitHub 계정)	로컬 컴퓨터	로컬 컴퓨터
기능	다른 사람 저장소를 내 계정의 원격 저장소로 복사	원격 저장소를 내 로컬로 복사	원격 저장소의 변경 사항을 로컬로 가져옴
명령/동작	GitHub 웹에서 Fork 버튼 클릭	`git clone <URL>`	`git pull origin main`
주 용도	오픈소스 기여, 원본 권한 없이 작업	프로젝트 시작, 첫 복제	협업 시 최신 변경 사항 반영
원본 연결	원본 저장소와 연결 유지 (업데이트 가능)	기본적으로 origin만 연결됨	origin(원격 저장소)에서 데이터 가져옴

Fork 후 작업 흐름

Github에서 Fork
1. 원본 저장소 페이지 → Fork 버튼 클릭 → 내 계정으로 복사됨
  ex) github.com/original-owner/project → github.com/my-account/project

내 Fork 저장소를 로컬에 Clone

git clone https://github.com/my-account/project.git

원본 저장소를 remote로 등록

git remote add upstream https://github.com/original-owner/project.git
git remote -v
# origin: 내 fork
# upstream: 원본 저장소

작업 및 커밋

git checkout -b feature/my-change
# 코드 수정
git add .
git commit -m "Add new feature"

내 fork에 push
```
git push origin feature/my-change
```
Pull Request 생성
1. Github에서 Compare & pull request 클릭
  1. 내 브랜치와 원본 브랜치의 차이가 없거나, Github가 자동 감지를 못 했을 때 버튼이 보이지 않을 수 있음
  2. 수동으로 Pull Request 생성
    - 원본 저장소 → Pull requests 탭 → New pull request → base: 원본 브랜치, compare: 내 브랜치
  3. 원본 브랜치와 차이가 있는지 확인
2. 원본 저장소로 변경 사항 병합 요청

오픈소스 협업 시, 내 fork가 원본보다 뒤처질 수 있으므로
→ upstream과 동기화 필요
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

협업 중 주의사항

작업 시작 전에 항상 git pull

집/회사 어디서든 작업 시작 전 최신화 필수

동일 파일을 양쪽에서 수정하면 충돌(conflict) 발생

Git이 자동 병합 불가하면 수동으로 수정 후 git add + git commit

브랜치 사용 고려

각각 브랜치에서 작업 → 마지막에 main 병합
→ 충돌 확률 줄어듦

ex) 집에서 작업 → push → 회사에서 pull → 작업 후 push → 집에서 pull → 이어서 작업

처음 학교에서 git 배울 땐 별로 와닿지 않았는데
지금 와서 느낀 게 언어만큼 능숙하게 다룰 줄 알아야 고생을 덜함
특히 병합... 프로젝트 규모가 조금만 커져도 수동 병합이 지옥이기 때문에
Pull Request 기능을 가능한 적극 활용하는 것이 좋은 듯

지금 글은 대충 개념을 모아 둔 메모에 가까워 좀 중구난방인데
나중에 더 익숙해지고 나서 전체적으로 수정해야겠다