Git 시작

git init                     # 현재 디렉토리를 Git 저장소로 초기화
git add .                    # 모든 파일 스테이지에 올리기
git commit -m "init"         # 초기 커밋 생성
git branch -M main           # 브랜치 이름을 main 으로 변경
git remote add origin <URL>  # 원격 저장소(origin) 등록
git push -u origin main      # 원격 저장소에 첫 푸시

#-----------------------------

git clone <URL>              # 원격 저장소를 로컬로 복제

-u 를 붙이는 이유는 로컬의 브랜치와 원격의 브랜치를 연결해주는 옵셥
이후 git pull, git push 를 브랜치명 없이 가능 하지만 git pull main, git push main 을 이름을 명시해준다면 않해도 됨

Git PR

git checkout -b feature/my-task            # 작업용 브랜치 생성 및 이동

# --- 여기서 코드 수정 작업 ---

git add .                                  # 변경 파일 스테이지
git commit -m "작업 내용"                    # 작업 커밋
git push -u origin feature/my-task         # 작업 브랜치를 원격에 업로드

# 이후 GitHub 웹 화면에서 "Compare & pull request" 클릭하여 PR 생성

Git branch

브랜치 목록 확인/생성/삭제

git branch          # 목록
git branch -d feat  # 삭제
git branch -M main  # 이름 변경

Git switch

git switch는 브랜치 이동을 직관적으로 만들기 위해 만들어진 명령어
기존의 git checkout이 너무 많은 기능을 한꺼번에 담당해서 혼란을 줄이기 위해 분리된 명령어

git switch main                 # main 브랜치로 이동
git switch -c feature/my-task   # 브랜치를 만들고 바로 이동

git checkout 을 하게 되면 파일이 변경되어 과거 버전을 보고 개발하게 될 수 있음 하지만 git switch 는 브랜치만 변경되기 때문에 그런일이 줄어듬

Git Checkout

checkout은 “브랜치 이동, 파일 복원”을 한 명령으로 처리하는 바람에 실수 위험이 크다.
작업 중이던 파일이 다른 브랜치 기준으로 덮어쓰여서 변경 중이던 코드가 사라지는 사고가 자주 발생
그래도, 특정 상황에서는 필요함

# --- 브랜치 이동 ---
git checkout main
git checkout feature/login
#대신 추천
git switch main                 # main 브랜치로 이동

# --- 새 브랜치 생성 + 이동 ---
git checkout -b feature/login
#대신 추천
git switch -c feature/login

# --- 파일을 특정 커밋 상태로 되돌리는 기능 ---
git checkout HEAD src/App.java
git checkout -- src/App.java
#대신 추천
git restore src/App.java

Git status

현재 작업 디렉토리에서 어떤 파일이 변경되었는지 확인하고 싶을 때
스테이지(add) 되었는지, 아직 unstaged 인지 확인하고 싶을 때
어떤 파일이 커밋 대산인지 보고싶을 때

git status
git add .
git status
git commit -m "msg"

# --- Untracked files (Git에 없는 파일) ---
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/test/Main.java
        
        
# --- Changes not staged for commit (변경됐지만 add 안 됨) ---
Changes not staged for commit:
  modified: src/app/UserService.java
  

# --- Changes to be committed (커밋될 준비가 된 파일) ---  
Changes to be committed:
  new file: src/app/OrderService.java
  modified: src/app/CartService.java
  
  
# --- 현재 브랜치 정보 / 리모트 상태 ---  
On branch feature/login
Your branch is ahead of 'origin/feature/login' by 2 commits.

# --- 충돌(conflict) 상황도 알려줌 ---  
Unmerged paths:
  both modified: src/app/UserService.java

Git merge

두 브랜치의 변경사항을 하나의 브랜치로 합치는 것

예를 들어:

• main branch
• feature/login branch
• feature 브랜치에서 작업을 끝내고 → main에 합칠 때 merger를 사용

git switch main               # 합쳐질(받아들일) 브랜치로 이동
git merge feature/login       # feature의 변경사항을 main에 합치기

main:      A — B — C — F
               \
feature:         D — E

# --- git merge ---

main:      A — B — C — F — M
               \           /
feature:         D — E ——

merge conflict

git merge feature/login
# <<<<<<< HEAD
# =======
# >>>>>>> feature/login

# --- 해당 파일을 직접 수정 후 ---

git add 파일명
git commit

merge는 언제 사용?

PR(풀 리퀘스트) 병합시

GitHub에서 PR을 만들고 → 리뷰 후 → Merge Pull Reqeust (내부적으로 merge를 수행)

main ← feature 작업 완료시

Git rebase

rebase = 내 브랜치 출발점을 (main 최신 지점)으로 옮기는 것

• 커밋을 다시 만들어서 직선을 만듦
• 공유 브랜치에서는 절대 사용하면 안됨(커밋 재작성되니 충돌과 히스토리 꼬임)

git switch feature
git rebase main

# rebase 후 원격 브랜치 업데이트
git push -f 
# or
git push -f <브랜치명>

# 더 안전하게는 
git push --force-with-lease
# or
git push --force-with-lease <브랜치명>

main:      A — B — C — F
               \
feature:         D — E

# --- git merge ---

main:      A — B — C — F
                        \
feature:                 D' — E'

rebase conflict

error: could not apply D
hint: Resolve conflicts and run `git rebase --continue`

#-----------------------------

<<<<<<< HEAD
main 버전의 코드
=======
feature 버전의 코드
>>>>>>> D

#-----------------------------

git add <충돌난파일>
git rebase --continue

rebase는 언제 사용?

1. main 브랜치가 업데이트된 상태에서 feature 브랜치를 최신으로 맞추고 싶을 때
2. feature 브랜치의 커밋을 깔끔하게 정리하고 싶을 때
3. PR 보내직 전에 히스토리를 직선으로 만들고 싶을 때
4. merge coimmit 이 싫을 때

feature 브랜치의 커밋을 깔끔하게 정리하고 싶을 때

D  (작업 커밋)
E  (오타 수정)
F  (테스트 로그 삭제)
G  (실제 기능 추가)

#-----------------------------

$ git log --oneline
g7f3abc G
c9b312f F
a4e129b E
d1f2c9a D

#-----------------------------

git rebase -i HEAD~4

# 아래 명령어 사용 가능:
# pick (그대로)
# squash(commit 합치기)
# reword(메시지 수정)
# drop(커밋 삭제)
#-----------------------------

pick d1f2c9a D
pick a4e129b E
pick c9b312f F
pick g7f3abc G

#-----------------------------

pick d1f2c9a D
squash a4e129b E
squash c9b312f F
pick g7f3abc G

#-----------------------------

D
# E
# F

#-----------------------------

기능 구현 + 오타 수정 + 로그 정리

#-----------------------------

new_hash2 G
new_hash1 기능 구현 + 오타 수정 + 로그 정리

Git restore

수정한 App.java 파일을 마지막 커밋 상태(HEAD)로 되돌림

• 수정했던 내용 → 모두 사라짐
• 파일은 커밋된 기준 버전으로 리셋됨
• add 되지 않은 변경사항(staged 전 변경)만 리셋됨

개발하다가 “이거 그냥 다시 처음부터 하자” 싶을 때 쓰는 명령어

src/App.java  ← 내가 수정함
# 근데 “아… 이거 아니네… 그냥 돌아가자” 하면
git restore src/App.java
# → 마지막 커밋 시점으로 돌아감

한번 더

# --- 파일 수정함 (아직 add 안 함) ---
git status

Changes not staged for commit:
    modified: src/App.java
# --- 복구 ---
git restore src/App.java

# --- 복구 후 상태 ---
git status
# nothing to commit, working tree clean
# 변경 내용 전부 사라짐

🟥 중요한 점!

git add src/App.java
git restore src/App.java  ❌ 안 됨