CS/모바일웹서비스프로젝트

1. Git & GitHub

arsenic-dev 2025. 10. 3. 02:15

경희대학교 안기옥 교수님의 모바일/웹서비스프로젝트 수업을 기반으로 정리한 글입니다.

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에 대한 설명을 작성하는 부분이다.

 

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(설명) 파일을 자동으로 생성해 주는 옵션

 

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"를 클릭하여 확인할 수 있다.