경희대학교 안기옥 교수님의 모바일/웹서비스프로젝트 수업을 기반으로 정리한 글입니다.
Ch 1. Git, Basic
Git은 소프트웨어 형상 관리(Software Configuration Management) Tool로, local application이다.
그리고 이러한 Git에 해당하는 서비스를 온라인에서 협업 가능하게 제공하는 게 GitHub이다.
- Software Configuration Management: 자동화된 시스템으로 하는 백업의 개념

Git은 소스코드 관리를 위한 분산 버전 관리 시스템이다.
분산 버전 관리 시스템이랑 파일의 스냅샷(버전)들을 전부 복제해 두는 것으로,
서버에 문제가 생겨도 이 복제물로 작업을 시작하거나 서버를 복원할 수 있다.
Git의 핵심
1. 델타가 아니라 스냅샷
- 파일에 대한 변화(델타)를 저장하는 것이 아니라 시간순으로 스냅샷을 저장
2. 대부분 명령을 로컬에서 실행
- 거의 모든 명령이 로컬 파일과 데이터만을 사용하기 때문에, 네트워크에 있는 다른 컴퓨터(서버)는 필요 X
- 오프라인 상태에서도 소스코드를 비교하고 Commit 할 수 있음
3. 세 가지 상태 및 단계
- Committed: 데이터가 로컬 데이터베이스에 안전하게 저장됨
- Modified: 수정한 파일을 아직 Commit 하지 않음
- Staged: 수정한 파일을 곧 Commit 할 거라고 표시함

- Working Directory: 프로젝트의 특정 버전을 Checkout 한 것
- Staging Area: 단순한 파일로 곧 Commit 할 파일에 대한 정보를 저장
- Repository: 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳
- "git init" 혹은 저장소를 Clone 할 때 만들어짐
※ 용어 설명
- Clone: 원격 저장소 전체를 로컬로 복사하는 것으로, 처음으로 프로젝트를 내 컴퓨터로 가져올 때 사용
- 그 결과, 로컬에 새로운 Repository가 생성되며, 바로 Working Directory에도 해당 브랜치가 만들어짐
- Checkout: 이미 내 로컬에 있는 Repository에서 특정 브랜치나 커밋의 상태를 Working Directory에 불러오는 것으로, 다른 브랜치로 이동, 혹은 과거 커밋 상태를 보고 싶을 때 사용
- 그 결과, Working Directory에 선택한 상태의 파일이 나타남
- 이때 Repository 자체가 바뀌는 건 아님, 단지 보는/작업하는 상태가 바뀜
4. 무결성
- 모든 데이터를 저장하기 전에 해시를 구하고, 이 해시로 데이터를 관리
- 파일을 이름이 아닌, 해당 파일의 해시로 저장
5. 데이터를 추가만 함
- 항상 데이터를 추가하며, 되돌리거나 데이터를 삭제할 방법 X (과거 히스토리 항상 보존)
- 이때 만약, 로컬에서 파일을 삭제하면 버전관리 대상이 아닌 파일로 인식함
Git에서는 아이디어를 실험하거나 기능을 개발하기 위해 브랜치를 자유롭게 만들고 커밋하며, 필요하면 원래 상태로 돌아가거나 패치를 적용할 수 있다. 즉, 제품 출시용 브랜치는 하나만 유지하고, 나머지는 테스트, 개별 이슈 등을 위해 마음껏 생성 후 작업하며, 완료되면 마스터 브랜치로 머지하고 불필요한 브랜치는 삭제할 수 있다. (히스토리 깔끔하게 유지하며 안전하게 개발 가능)
Installing & Configuring Git (Windows)
1. Git 설치
| 실행 환경 | 특징 |
| Git Bash | Linux 터미널 환경 |
| Git CMD | Windows cmd 환경 |
| Git GUI | 그래픽 환경 |
2. 사용자 이름과 이메일 주소 설정
- commit 할 때마다 이 정보를 사용하여 기록
- Github에서 커밋 소유자를 계정과 연결하려면, 커밋에 기록된 이메일이 해당 계정에 등록된 이메일과 일치해야 함
$ git config --global user.name "이름"
$ git config --global user.email "sy040103@khu.ac.kr"
Creating a new repository
: 새 Git 프로젝트를 시작
$ git init
기존 프로젝트를 Git으로 관리하기 위해선 프로젝트의 디렉토리로 이동해서 위 커맨드를 실행하면 된다.
위 커맨드는 '.git'이라는 하위 디렉토리를 만들고, '.git' 디렉토리에는 저장소에 필요한 뼈대파일이 들어있다.
Checking the status
: 현재 프로젝트(Working Directory)에서 파일 상태 확인
$ git status
위 커맨드를 사용하여 파일의 수정 상태와 Track 상태를 확인한다.
- modified: Git이 추적 중인 파일이 수정됨
- staged: "git add"로 커밋 준비 완료
- Untracked 파일: Git이 아직 추적하지 않는 새 파일
- Untracked 상태라면 스냅샷(Commit)에 넣어지지 않은 파일이기 때문에 Git은 절대로 그 파일을 Commit 하지 X
- 즉, 새로 만든 파일을 "git add"로 스테이징 영역에 올려야 커밋 가능
Staging
: 커밋할 파일을 대기 상태로 올려놓는 단계
$ git add "파일 이름"
위와 같이, 특정 파일을 추가할 수도 있으며, "git add ." 혹은 "git add -A"를 사용하여 모든 변경 사항을 한 번에 등록할 수도 있다.
Commiting
: 스테이징 영역에 있는 내용을 로컬 저장소(repository)에 기록
$ git commit -m "commit message"
Commit은 특정 시점의 저장소 상태를 나타내는 스냅샷으로, 언제든지 돌아갈 수 있는 특정 지점을 생성한다고 볼 수 있다.
이러한 Commit을 생성하려면 최소한 하나의 변경 사항이 Staging area에 추가되어야 한다.
commit message는 commit에 대한 설명을 작성하는 부분이다.
- commit message 작성법: https://arsenic-dev.tistory.com/11
Ch2. Git, Remote repositories
Connecting to a remote repository
: 프로젝트의 모든 스냅샷을 원격 저장소에 업로드하여 관리하기 위해서는 Github, Gitlab 등의 서비스에 연결 필수
$ git remote add origin <원격 저장소 주소>
※ 원격 저장소의 이름은 origin으로 쓰는 것이 기본이다.
Uploading to a server
: 로컬에서 작업한 Commit을 서버로 전송하는 Push (원격 저장소를 업데이트 할 때마다 수행)
$ git push origin main
※ origin: 원격 저장소 이름 / main: branch 이름
Cloning a repository
: 자신 혹은 다른 사람의 원격 저장소에 있는 Repository를 가져와 사용하는 Clone
$ git clone <원격 저장소 주소>
원격 저장소와 동일한 로컬 repository가 자동으로 생성된다. (프로젝트의 전체 복사본 생성)
Getting changes from a server
: 원격 저장소로부터 변경 사항 다운로드
$ git pull origin main
하나의 로컬에서 같은 프로젝트를 작업하기 위해 매번 Clone 할 필요는 없다.
즉, 이미 한 번 Clone 하여 로컬 저장소를 만들었다면, 그 다음부터는 Clone이 아니라 Pull을 써야 한다.
- clone: 프로젝트 처음 받을 때 사용
- pull: clone 이후, 바뀐 부분에 대해 동기화하기 위해 사용
Ch3. Git, Branches

Branch란 개발자들이 독립적으로 작업할 수 있도록 만들어진 기능으로, 서로 영향을 주지 않고 동시에 다양한 작업을 진행할 수 있다. 이후 작업이 완료되면 병합(Merge)을 통해 여러 Branch의 내용을 하나로 통합할 수 있다.
Creating new branch
: main Branch 외에, 추가적으로 새로운 Branch 생성
$ git branch <사용자 정의 이름>
Branch를 만들었다고 해서 Branch가 전환되는 것은 아니다.
Switching branch
: branch 목록 확인 및 branch 전환
$ git branch # branch 목록 확인 (현재 Branch는 '*'로 표시)
new_branch
* main
$ git checkout new_branch # branch 전환
Branch를 전환하기 전에 현재 생성된 모든 Branch를 확인하고 변경하여야 어떤 Branch를 사용할지 정확히 알 수 있다.
Merging, Removing branch
: branch 병합 및 필요 없는 branch 정리
$ git add testBranch.txt # 파일 추가
$ git commit -m "Add new feature" # 커밋
$ git checkout main # main branch로 전환
$ git merge new_branch # main branch에 new_branch의 커밋 내용 합침 (branch 병합)
$ git branch -d new_branch # 모든 사항이 병합된 필요 없는 branch 정리
Ch4. Git, Advanced
Checking difference commits
: Commit 기록 확인 -> 이전 상태로 회귀 or 어떤 파일이 수정되었는지 확인
$ git log # 커밋 기록만 간단히 출력 (커밋 아이디, 작성자, 날짜, 메시지 확인)
$ git log -p # 커밋 기록 + 실제 수정된 코드(diff) 같이 출력 (p: patch)
$ git diff <스냡샷 id1> <스냅샷 id2> # 특정 두 버전 사이의 차이점 비교
Setting up .gitignore
: .gitignore은 Git이 버전 관리하지 말아야 할 파일/폴더를 지정하는 파일 (커밋하고 싶지 않은 파일 e.g., cache, tmp, lib)
.gitignore 파일 만드는 법은 다음 순서를 따른다.
- 수동으로 ".gitignore"이라는 텍스트 파일을 만들고 프로젝트 디렉토리에 저장
- 내부에 무시할 파일, 디렉토리의 이름을 한 줄에 하나씩 나열
- ".gitignore" 파일을 Commit 하여 등록
- 이후, ".gitignore"에 등록된 파일, 디렉토리는 Commit에 추가되지 않음
# 1. .gitignore 생성
touch .gitignore # 또는 에디터로 새 파일 생성
# 2. 무시할 항목 추가 (한 줄에 하나씩)
echo "libs/" >> .gitignore # 줄 끝의 '/'는 폴더라는 것을 나타내고 하위 폴더 역시 무시하게 함
echo "*.log" >> .gitignore # '*'은 확장자가 ".log"인 모든 파일 무시하게 함
# 3. .gitignore 커밋
git add .gitignore
git commit -m "Add .gitignore"
※ 코드 설명
- touch: 빈 파일을 새로 만들거나, 이미 있으면 수정 시간을 갱신하는 명령어
- echo: 문자열을 화면에 출력하는 명령어
- >> 연산자: 출력 결과를 파일 끝에 추가 (append)
와일드카드
파일 이름이나 문자열에서 특정 패턴을 표현할 때 쓰는 특수 문자로, 아무거나 대신 쓸 수 있는 기호이다.
1. *
- 모든 문자(0개 이상)를 의미
- 예시)
- *.log -> 확장자가 .log인 모든 파일 (e.g., error.log, debug.log)
- abc* -> abc로 시작하는 모든 파일 (abc.txt, abc123.py)
2. ?
- 아무 글자 1개를 의미
- 예시)
- file?.txt -> file1.txt, fileA.txt O / file10.txt X
3. [ ]
- 대괄호 안에 들어간 글자 중 하나를 의미
- 예시)
- file[12].txt -> file1.txt, file2.txt
Return to a specific commit
: 이전의 특정 상태로 돌아가야 하는 경우 사용 (Commit 이력도 이전 상태로 돌아가니 주의)
$ git log # log 명령어를 실행하여 commit 이력 확인
commit 5c897704302ca57cdc236ba29d7d57550a8d8490
...
commit d6bac0101f29850ae5b43031d7429660407fc45e
$ git reset d6bac0101f29850ae5b43031d7429660407fc45e // 돌아가려는 Commit의 아이디를 입력
Resolving Merge Conflicts(병합 충돌)
: 각각의 Branch에서 변경한 내용이 같은 파일의 같은 행에 포함되어 있으면 충돌 발생 -> 충돌이 있는 부분 직접 수정
수정 후, Commit하고 Merge 하면 정상적으로 작동한다.
하지만 이왕이면, 같은 파일을 동시에 수정하지 않는 것이 안전하다.
Ch5. GitHub
Repository 생성
: "New repository" 클릭 후, Repository의 이름과 설명 작성

Readme 생성 옵션을 체크하고, 다음 페이지에 나오는 gitignore, License도 함께 설정하면 편하다.
※ License 파일: 프로젝트(특히 오픈소스 프로젝트)를 사용할 때 "이 코드를 다른 사람이 어떻게 사용할 수 있는지" 규칙을 정해놓는 문서이다. (e.g., 코드를 다른 사람이 쓸 수 있는지, 고쳐도 되는지, 상업적으로 써도 되는지)
Repository 생성 후에는, Settings를 클릭하여 Features 부분에 있는 옵션들을 설정할 수 있다.
- Wikis: 프로젝트 문서/가이드북을 작성할 수 있는 공간
- Restrict editing to collaborators only: 저장소 참여자만 위키 수정 가능하도록 제한
- Issues: 버그 신고, 기능 요청 등 할 일을 기록하고 토론할 수 있는 공간 (일종의 게시판 시스템)
- Projects: 칸반보드 형식으로 작업(Task)을 시각적으로 관리할 수 있는 기능
Branch 생성 및 보기

위 그림처럼 Branch 버튼을 누르고 명령창에 생성할 이름을 써주면 Branch가 생성된다.
이때, 특정 Branch의 이름을 클릭하면 해당 Branch로 자동으로 전환되어 그 Branch의 파일을 볼 수 있다.
Commit history 보기

Repository 메인 페이지에서 Commit을 클릭할 경우, 위와 같이 모든 Commit history를 볼 수 있다.
이것은 "git log"와 동일한 기능을 가지고 있다.
Commit history에서 Commit 하나를 클릭할 경우,
세부적으로 어떤 파일이 Commit 되었는지, 파일의 어느 부분이 수정되었는지 볼 수 있게 된다.
Pull request (PR)
: 내 코드(branch)를 팀원 리뷰를 거쳐 main branch에 넣어달라는 요청 -> 문제 없을시 Merge

main으로의 Merge는 Project Leader (PL) 혹은 다른 팀원의 리뷰 후에 올리는 것이 추후 오류가 적다.
Issue

Issue 기능은 여러가지로 사용될 수 있는데, 주로 사용되는 것은 기능에 대한 논의, 버그 추적, 오류 발생에 대한 내용 작성 및 팀원 간의 소통을 위해 사용된다.
이후 사용법
: 원격 저장소 생성 후 clone 하여 사용하거나, 프로젝트가 개발 도중이었다면 "git init" 후 원격 저장소 등록을 통해 사용 가능
원격 저장소의 주소는" Clone or download"를 클릭하여 확인할 수 있다.
'CS > 모바일웹서비스프로젝트' 카테고리의 다른 글
| 4. Django, 이미지 블로그와 REST API (0) | 2025.10.11 |
|---|---|
| 3. Debugging Django with VSCODE (0) | 2025.10.09 |
| 2. Django 웹 프레임워크 (0) | 2025.10.09 |