AWS Cloud School 13기 2일차

오늘은 12월 24일 크리스마스 이브입니다. Git과 Github를 배웠습니다.
오늘부터 배운 내용을 정리하는 블로그로 작성해보겠습니다.

환경 설정

git을 사용하기 전에 반드시 사용자 정보를 설정

git config --global user.name "홍길동"
git config --global user.email "www@naver.com"

설정 확인하기

git config --list
# 또는 특정 항목만
git config user.name
git config user.email

---

Git의 세 가지 영역

영역	설명	비유
Working Directory	실제로 파일을 편집하는 공간	책상 위
Staging Area	커밋할 파일을 준비하는 공간	택배 박스
Repository	변경 이력이 저장되는 공간	창고

저장소 만들기 : git init

Git을 사용하기 위해서는 저장소를 초기화해야 한다.

mkdir my-project
cd my-project

# Git 저장소 초기화 
git init

git init을 실행하면 .git이라는 숨김 폴더가 생성

---

상태확인 : git status

현재 저장소의 상태를 알려준다.

git status

---

git add

커밋하고 싶은 파일을 이제 staging area에 올린다.

# 특정 파일
git add hello.txt
# 현재 디렉토리의 모든 변경사항 추가
git add .

---

git commit

staging area에서 저장소에 기록

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

좋은 예시(무엇을 변경했는지, 왜 변경했는지, 한줄로 요약)

feat : 소셜 로그인 기능 추가
fix : 장바구니 수량 음수 입력 방지
docs : API 사용법 문서화

---

이력 확인 : git log

# 전체 로그
git log
# 한 줄씩 간단히
git log --online
# 그래프로 보기
git log --oneline --graph

---

.gitignore란?

.gitignore는 Git이 무시한 파일 목록을 정의하는 특별 파일이다.

# 프로젝트 루트에 생성
touch .gitignore

왜 필요하는가?

무시해야 할 것	이유
환경 설정 파일	.env, config.local.js 등 비밀번호/API 키 포함
빌드 결과물	dist/, build/ 등 언제든 다시 생성 가능
의존성 폴더	node_modules/, venv/ 등 용량이 크고 재설치 가능
IDE 설정	.idea/, .vscode/ 등 개인 환경 설정
의존성 폴더	.DS_Store, Thumbs.db 등 불필요한 시스템 파일

---

.gitignore 문법

기본 패턴

# 특정 파일 무시
secret.txt
.env

# 특정 확장자 무시
*.log
*.tmp

# 특정 폴더 무시 (끝에 / 붙이기)
node_modules/
dist/
build/

# 루트 디렉토리의 파일만 무시
/config.local.js

# 하위 모든 디렉토리에서 무시
**/logs/

예외 처리 (!)
#모든 .log 파일 무시
*.log

# 하지만 important.log는 추적
!important.log

실무 예시 : Node.js 프로젝트

# 의존성
node_modles

# 빌드 결과
dist/
build/

# 환경 설정
.env
.env.local
.env.*.local

# 로그
*.log
npm-debug.log*

# IDE
.idea/
.vscode/
*.swp

# OS
.DS_Store
Thumbs.db

# 테스트 커버리지
coverage/

---

HEAD에 대해서

HEAD란 무엇인가?

"현재 작업 중인 위치"를 가리키는 포인터

왜 필요하는가?
git의 모든 명령어는 "어디서부터 작업할 것인가"를 알아야 한다.

• git commit : 어떤 커밋 위에 새 커밋을 쌓을지
• git diff : 무엇과 비교할지
• git merge : 어느 브랜치로 병합할지
• git reset : 어디로 되돌릴지

HEAD 확인하는 방법

1. git log로 확인

git log --oneline -5

--oneline : 각 커밋을 한 줄로 압축하여 표시(해시 7자리 + 메시지)
-5 : 최근 5개의 커밋만 표시

2. git branch로 확인

git branch

*  : 현재 HEAD가 가리키는 브랜치

3. HEAD 파일 직접 확인

cat .git/HEAD

---

Detached HEAD 상태

언제 발생 할까?

# 특정 커밋으로 직접 체크아웃
git checkout abc1234

# 또는 태그로 체크아웃
git checkout v1.0.0

해결 방법
1. 작업 전에 브랜치 만들기

# 현재 위치에서 새 브랜치 생성 + 체크아웃
git checkout -b experiment-brach

2. 작업 후에 브랜치 만들기

# 현재 HEAD 위치(방금 만든 커밋 포함)에서 새 브랜치 생성
git branch save-my-work
# 또는 생성과 동시에 체크아웃
git checkout -b save-my-work 

3. 실수로 이동한 후 복구하기

git reflog

---

Branch

브랜치(Branch)는 독립적인 작업 공간을 만드는 기능

브랜치 명령어

브랜치 목록 확인

git branch
# * main     <- * 표시가 현재 브랜치
#   feature

브랜치 생성

# 새 브랜치 생성 (이동하지 않음)
git branch feature/login
# 생성과 동시에 이동
git switch -c feature/login

브랜치 삭제

# 병합된 브랜치 삭제
git branch -d feature/login
# 강제 삭제(병합 안 된 브랜치)
git branch -D feature/login

브랜치 이동 : git switch

# 다른 브랜치로 이동
git switch feature/login
# main 브랜치로 돌아가기
git switch main

브랜치 전략

접두사	용도	예시
main/master	배포 가능한 안정 버전	-
develop	개발 통합 브랜치	-
feature/	새 기능 개발	feature/login
bugfix/	버그 수정	bugfix/cart-error
hotfix	긴급 수정	hotfix/security

---

Merge & history

병합은 두가지의 상황이 있다.
1. Fast-forward(나만 일했을 때)
2. 3-Way Merge(둘 다 일했을 때)

3-Way Merge

두 브랜치가 서로 다른 커밋을 가지게 되는 순간 브랜치는 갈라진다.
Git은 3개를 비교해서 "공통 조상 이후로 각각 뭐가 바뀌었는지" 파악하고, 자동으로 합친다.

명령어 정리

# 1단계 : 합칠 "목적지" 브랜치로 이동
git switch master
# 2단계 : 가져올 브랜치를 병합
git merge feature/login
# 병합 도중 취소하고 싶을 때
git merge --abort

master에서 feature를 가져온다.

충돌(Confilct)

두 브랜치가 같은 파일의 같은 줄을 수정했을 때 발생
그중 우리가 확인하고 고친다

<<<<<<<< HEAD
<h1> 우리 사이트에 오신 것을 환영 </h1>
======
<h1> 내 사이트에 오신 것을 환영 </h1>
>>>>>>>> featuer/login

표시	의미
<<<<<<<< HEAD	여기서부터 현재 브랜치의 내용
======	구분선
>>>>>>>> featuer/login	여기까지 병합하려는 브랜치의 내용

---

Remote & collaboration

원격 저장소란?

원격 저장소는 인터넷이나 네트워크에 있는 Git 저장소이다.
ex) Github, GitLab, Bitbucket

git remote : 원격 저장소 연결

원격 저장소 추가

# 원격 저장소 추가
git remote add origin https://~
# 등록된 원격 저장소 확인
git remote -v
# 원격 저장소 이름 변경
git remote rename origin upstream
# 원격 저장소 삭제
git remote remove origin
# 원격 저장소 URL 변경
git remote set-url origin

git push : 로컬 -> 원격

로컬 저장소의 커밋을 원격 저장소로 업로드

# 기본 push
git push origin main
# 최초 push시 upstream 설정
git push -u origin main
# 이후에는 git push 만으로 가능

# 강제 push (주의!)
git push -f origin main

push 거부 상황

원격 저장소에 로컬에 없는 새로운 커밋이 있을때 Git은 데이터 손실을 막기 위해 push를 거부한다.
해결 방법
1단계 : pull로 원격 변경사항 가져오기

git pull origin main

2단계 : 충돌 해결

• 충돌이 없는 경우

git pull origin main

• 충돌이 있는 경우

git pull origin main

# 1. 충돌 파일 수정
# 2. 스테이징
git add file.txt

# 3. 병합 완료
git commit

3단계 : 다시push

git push origin main

그래서 예방법은 작업 전 항상 pull을 한다.

---

git pull : 원격 -> 로컬

원격 저장소의 변경 사항을 로컬로 다운로드하고 병합한다.

git pull origin main
# upstream이 설정 되어 있으면 
git pull# 

pull = fetch + merge

git fetch origin  # 원격 데이터 다운로드(병합 X)
git merge origin/main # 로컬 브랜치에 병합

# 또는 한번에
git pull origin main

---

git clone : 가져오기

이미 존재하는 원격 저장소를 통째로 복사한다.

# 저장소 복제
git clone https://~
# 특정 폴더명으로 복제
git clone https://~
# 특정 브랜치만 복제
git clone -b develop https://~

그럼 clone vs init의 차이는 무엇인가?

• Clone : 기존 원격 저장소를 가져올 때
• init : 새 저장소를 처음 만들 때

실습 문제
1. GitHub에서 새 저장소(repository)를 생성하세요. (README 없이)
2. 로컬의 기존 프로젝트에 원격 저장소를 연결하세요.
3. 로컬 커밋을 원격으로 push하세요.

4. GitHub 웹사이트에서 파일이 올라갔는지 확인하세요.
5. GitHub 웹에서 README.md 파일을 직접 추가하세요.
6. 로컬에서 pull을 실행하여 README.md를 가져오세요.

---

코드 리뷰, Pull Request

Pull Request는 "내 코드 좀 봐주세요"라고 팀원에게 요청하는 것이다.
커밋 메시지 작성법
종류: 설명 형식으로 씁니다.

종류	언제 사용?	예시
feat	새 기능 추가	feat: 로그인 기능 구현
fix	버그 수정	fix: 로그인 버튼 안 눌리는 문제 해결
docs	문서 수정	docs: README에 설치 방법 추가
style	코드 스타일 변경 (동작은 같음)	style: 들여쓰기 수정
refactor	코드 구조 개선 (동작은 같음)	refactor: 로그인 함수 분리

push 후 출력 메시지

remote: Create a pull request for 'feature/login' on GitHub by visiting:
remote:   https://github.com/내아이디/내저장소/pull/new/feature/login

→ 이 링크를 클릭하면 바로 PR 만드는 페이지로 갑니다!

PR 생성하기 (GitHub 웹사이트)

방법 1: push 후 나온 링크 클릭

방법 2: GitHub 저장소 방문 → "Compare & pull request" 버튼 클릭

방법 3: Pull requests 탭 → "New pull request" 클릭

PR 작성 화면

┌─────────────────────────────────────────────────┐
│  base: main  ←  compare: feature/login          │
├─────────────────────────────────────────────────┤
│  Title: feat: 로그인 기능 구현                    │
├─────────────────────────────────────────────────┤
│  Description:                                   │
│  ┌───────────────────────────────────────────┐  │
│  │ ## 무엇을 했나요?                          │  │
│  │ 로그인 기능을 만들었습니다.                 │  │
│  │                                           │  │
│  │ ## 왜 했나요?                              │  │
│  │ 사용자가 로그인할 수 있어야 하기 때문입니다. │  │
│  │                                           │  │
│  │ ## 어떻게 테스트하나요?                    │  │
│  │ 1. 로그인 페이지 접속                      │  │
│  │ 2. 아이디/비밀번호 입력                    │  │
│  │ 3. 로그인 버튼 클릭                        │  │
│  └───────────────────────────────────────────┘  │
├─────────────────────────────────────────────────┤
│  Reviewers: (리뷰해줄 사람 지정)                 │
├─────────────────────────────────────────────────┤
│  [Create pull request]                          │
└─────────────────────────────────────────────────┘

주니어가 자주 하는 실수

❌ PR 설명 안 쓰기

Title: 수정함
Description: (비어있음)

✅ 올바른 예시

Title: feat: 로그인 기능 구현
Description:
- 이메일/비밀번호로 로그인하는 기능입니다
- 로그인 실패 시 에러 메시지가 표시됩니다
- 관련 이슈: #42

---

리뷰 받기

PR을 만들면 리뷰어가 코드를 확인

리뷰 결과의 종류

결과	아이콘	의미
Comment	💬	그냥 의견이에요 (참고만 하세요)
Approve	✅	좋아요! 합쳐도 됩니다
Request changes	🔴	수정 필요해요! 고쳐주세요

피드백 받았을 때 대응법

# 1. 내 브랜치로 이동 (이미 있다면 생략)
git switch feature/login

# 2. 코드 수정
# ... 파일 수정 ...

# 3. 다시 커밋
git add .
git commit -m "fix: 리뷰 피드백 반영"

# 4. push하면 PR에 자동으로 반영됨!
git push

이렇게 PR까지 공부를 해보았습니다.
Github CLI(gh)도 공부를 했지만 이 기능은 먼저 Git에 대해 익숙해지고 나서
따로 정리를 하는 방식으로 해보겠습니다.

출처 : https://github.com/ej31