Git(깃) 기본 기능 및 사용법

Git (깃) 기본 기능 및 사용법

깃의 주요 구성 요소

Working directory: 실제로 개발자가 작업하는 공간
Staging area: git add를 통해 변경사항이 1차로 저장되는 공간
Local repository: 내 PC에 있는 저장소. git commit을 통해 최종적으로 저장되는 공간.
Remote repository :서버(GitHub 등)에 있는 저장소. 네트워크 상의 다른 위치에 존재하며 여러 사람이 함께 공유할 수 있는 공간

기본 용어

clone

(서버에 있는) remote repository에 저장된 저장소(레포지토리)를 내 working directory (컴퓨터)로 다운받는 것.

add

기존 서버에 업로드된 코드와 비교해서 현재 working directory에서 일어난 변경 사항을 staging area로 옮기는 명령어입니다.

commit

(실제로 가장 많이 쓰이는 것) staging area에 있는 변경 사항을 local에 존재하는 git의 저장소로 옮기는 것입니다. 변경사항의 스냅샷을 저장소에 기록하는 것. 게임 세이브포인트랑 같은 개념.

기본 커밋 흐름

작업 디렉토리          스테이징 영역          로컬 저장소
(Working Directory) → (Staging Area)    →  (Repository)
  파일 수정/생성          git add               git commit

권장 흐름

# 권장 흐름: 확인 → 선택 → 커밋
git status                    # 뭐가 바뀌었는지 확인 (항상 먼저!)
git add <파일>                # 원하는 파일만 스테이징
git commit -m "메시지"          # 커밋

스테이징은 변경한 파일이 여러 개여도 그중 원하는 것만 선택해서 커밋할 수 있게 해 줍니다.

commit 은 항상 최소 단위로 하는 습관을 들이는 게 좋습니다.
commit 메시지는 일관성 있게 그리고 팀의 양식에 맞춰서 작성하는 게 좋습니다.

커밋 전 체크리스트

푸시 버튼 누르기 전, 이 5가지만 확인하세요.

1. ☐ git status로 '무엇이' 바뀌었는지 눈으로 확인했나?
2. ☐ 내가 작업한 파일만 스테이징 했나? (남의 파일/모르는 .uasset 섞이지 않음)
3. ☐ 코드 커밋과 애셋 커밋을 섞지 않았나? (따로 따로 나눠서 커밋하자)
4. ☐ 커밋 메시지를 규칙대로 적었나? (feat/fix/docs…)
5. ☐ 푸시 전 플레이 테스트로 켜지는지 확인했나?

push

Local Repository (내 PC)에 저장된 변경 사항들을 최종적으로 Remote Repository (서버)로 옮기는 것

pull

push와 반대 개념, Remote Repository에서 Local Repository로 옮기는 것.

clone과의 차이는 clone은 처음에 (local repository에) 아무것도 없을 때, pull 은 변경된 사항들을 가져올 때

pull request

다른 사람들과 협업 시, 해당 브렌치에 나의 코드를 합치는 것에 대해서 요청하는 것.

내 feature 브랜치
       ↓
   PR 생성 (병합 요청)
       ↓
  팀원 코드 리뷰
       ↓
  수정 / 토론
       ↓
  승인 (Approve)
       ↓
   main에 Merge

main(master)

main(master) branch는 기본적으로 만들어지는 작업 공간이며 보통, 오류 없는 최종 코드가 저장되는 공간으로도 쓰입니다. (이름을 바꾸거나, 꼭 이걸 최종으로 쓰지 않아도 상관없습니다)

branch

실제로 작업하는 공간. 현재 commit에 대한 코드를 통째로 복사해서 다른 branch의 코드와 상관없이 독립적인 개발 공간을 제공해 주는 도구입니다.

merge

병합: branch + branch 혹은 branch와 main을 합치는 것

언리얼에서 .uasset / .umap 은 바이너리 파일이라 코드 리뷰가 사실상 불가능함.

✅ PR로 리뷰하기 좋은 것       ❌ PR 리뷰가 어려운 것
─────────────────────────      ──────────────────────
C++ 소스 코드 (.cpp / .h)      .uasset (바이너리)
Config 파일 (.ini)             .umap (레벨 파일)
빌드 스크립트                  Blueprint (일부)
.gitignore / .gitattributes

Git Repository (깃 저장소) 만들기

깃허브 방문하여 우측 상단 프로필 → Your repositories → new를 눌러서 생성합니다.

이후 아래의 정보들을 모두 작성하여 레포지토리를 생성하시면 됩니다.

Repository name: 현재 생성하는 저장소 이름
Description: 레포지토리의 설명란으로 선택사항
Public / Private: 레포지토리의 공개/비공개 여부 결정
- 게임 제작할 때 에셋들을 다운받아서 만드는데, 이때 아무리 무료로 받은 에셋들 이어도, 해당 에셋의 (라이센스 조항) 저작권 조항에 GitHub에서 공개로 해두는 것을 금지하는 조항들이 대부분 들어가 있기 때문에, 에셋 사용 시 Private을 추천합니다.
  - CC0 라이센스는 Public 이어도 괜찮을 것으로 나옵니다.
README file: 레포지토리를 설명을 자세하게 작성할 수 있는 파일로, 레포지토리를 잘 구성하고 싶다면, 생성해야 함
- 리포지토리 생성 후 추후에 만들어도 괜찮지만, 어차피 만들어야 할 거 그냥 처음부터 만드는 것을 추천합니다.
.gitignore: Git 버전 관리 시스템에서 추적하거나 업로드할 필요가 없는 파일 및 폴더를 지정하여 무시하도록 하는 설정 파일입니다. 보안유지, 용량 절약, 등등 을 위해서 설정합니다. (그래서 유니티나 언리얼 엔진 사용할 경우 해당 파일을 ignore 세팅해 둡니다). 이것도 추후에 .gitignore 파일을 수정 가능하지만 그냥 처음부터 세팅해 두는 것을 추천합니다. 추후 따로 만들 시 도움 되는 사이트: https://www.toptal.com/developers/gitignore/
- 보안 유지: API 키, 데이터베이스 비밀번호, 민감한 설정 정보(예:. env) 등이 원격 저장소(GitHub 등)에 올라가는 것을 방지합니다.
- 저장소 용량 절약: 빌드 결과물, 컴파일된 파일, 대용량 로그 파일 등을 제외하여 저장소를 가볍게 유지합니다.
license: 크게 오픈소스 라이센스 (모두에게 무료로 공개) / 클로즈드 라이센스로 나눌 수 있는데 무료 오픈소스의 경우 주로 MIT나 Apache2.0으로 나뉩니다.
- 오픈소스
- MIT: 라이센스 및 저작권을 명시해야 하고, 상업적, 사적으로도 이용이 가능하고, 수정/배포/특허 신청이 가능합니다. 제약조건이 상당히 느슨한 편이어서 많은 오픈소스들이 MIT라이선스를 사용합니다
- Apache: 누구나 해당 소프트웨어를 개인적, 상업적 목적으로 자유롭게 이용, 수정, 배포할 수 있는 ‘허용적(Permissive) 오픈소스 라이선스’입니다
- 클로즈드 라이센스
- 유료 게임의 경우 별도의 오픈소스 라이선스를 명시하지 않거나(None), 독점 라이선스(Proprietary License)를 직접 작성하여 적용해야 합니다.
- 깃허브에 코드를 공개하더라도 누구나 내 게임을 무단으로 복제, 배포하거나 상업적으로 이용하는 것을 막기 위해서입니다. 목적에 맞는 세부적인 라이선스 선택 및 적용 방법은 다음과 같습니다.
- 1. 기본 권리 유지 (라이선스 없음 / None)
  - 특징: 깃허브에서 라이선스 항목을 'None'으로 두거나 파일을 추가하지 않으면, 기본 저작권법이 적용되어 모든 권리(All Rights Reserved)를 개발자가 독점합니다.
  - 적용 대상: 소스 코드를 비공개로 안전하게 보관하거나, 코드는 열람만 가능하게 하되 상업적 이용 및 재배포를 전면 금지할 때 적합합니다.
- 2. 독점 라이선스 (Proprietary License)
  - 특징: 개발자가 직접 'LICENSE' 파일을 생성하여 "상업적 이용 불가", "무단 배포 금지" 등의 구체적인 사용 조건을 명시하는 방식입니다.
  - 적용 방법: LICENSE라는 이름의 파일을 생성한 후, 아래와 같은 표준 독점 라이선스 문구를 추가합니다.

Git(깃) 기본 기능 및 사용법