버전 관리(Version Control)란?

| 의미

  • 소프트웨어 등을 개발할 때 어떤 내용을 어느 시점에 누가 변경했는지에 대한 변경점을 관리하는 것이다.

 

|  주요 목적

  • 프로젝트의 변경 사항 추적 및 이전 버전으로의 복원이나 협업 용이하게 하기 위함이다.
  • 소프트웨어 개발 생명 주기 관리에 도움을 준다.

∴ 버전 관리를 효과적으로 수행할 수 있는 도구 = 버전 관리 시스템 = VCS(Version Control System)

 

Tmi - 피그마에서는 버전 관리를 알아서 해준다는 사실! version history가 자동 저장된다고 하며, Grammarly Editor의 메뉴에서 확인할 수 있다고 한다.

 

| 버전 관리 시스템의 종류

  1. 로컬 버전 관리 시스템 - SCCS, RCS
    • 서버 없이 로컬에서 데이터베이스 사용하여 버전 관리
  2. 중앙 집중식 버전 관리 시스템 - CVS
    • 서버에서 최종 버전을 관리하는 방식
    • 로컬에서 서버의 파일을 다운로드하여 수정한 후 수정 내용 서버에 반영하여 관리
    • 중앙 서버에서 문제 생기면 버전 관리 망..
  3. 분산식 버전 관리 시스템 - SVN, Mercurial, Git🌟
    • 중앙 집중식과 동일하게 서버가 있지만, 로컬에서도 관리를 하기 때문에 서버에 문제 생겨도 로컬 내용을 바탕으로 안전하게 버전 관리 가능!

 

Git

  • 이제 내가 주로 사용할 버전 관리 시스템인 Git은 2005년 리누스 토발즈가 리눅스 커널 프로젝트를 위해 개발한 분산 버전 관리 시스템이다.

 

| Git을 사용하는 이유!

  • 버전 관리나 협업에 매우 효과적이라는 것! etc..

 

| Git의 상태와 영역

Working Directory

실제로 파일들이 존재하고 작업되는 곳

 Staging Area

변경된 파일들 중 Git이 추적하길 바라는
파일들을 일시적으로 저장하는 곳		 Repository

실제 Git이 관리하는 데이터가 저장되고,
프로젝트의 모든 버전 기록이 담기는 곳

(이 개념 덕분에 Git을 이해하기가 더욱 쉬웠다!!)

 

| 작업의 흐름

(파일 수정) →  Working Directory → (Git이 추적하길 바라는 파일) → Staging Area → (Commit) → Repository

  • 로컬 저장소는 Git이 관리하는 세 그루의 나무로 구성되어 있다.
  • 첫 번째 나무인 작업 디렉터리(Working directory / ex. index.html)는 실제 파일들로 이루어져 있다.
  • 두 번째 나무인 인덱스(index / ex. new file: index.html)는 준비 영역(Staging area)의 역할을 한다.
  • 마지막 나무인 HEAD는 최종 확정본(commit / ex. commit 12962853f10271f81c15cb0b7024e0351338c204 (HEAD -> main) )을 나타낸다.

예시 사진

| Git 환경 설정

  • Windows의 경우 gitbash를 기본 shell로 설정 필요 (Command Palette → Select Default Profile → gitbash)
git config --global user.name 사용자명 # Git 사용자 ID 등록
git config --global user.email 이메일 # Git 사용자 Email 등록
git config --global core.editor "code --wait" # Git Default Editor 설정 (Visual Studio Code)

# windows와 Mac OS의 공백문자(줄바꿈) (Carriage return, Lind Feed)

# Windows 환경
git config --global core.autocrlf true # autocrlf는 true로 유지
git config --global advice.ignoreCrLfWarning true # 줄바꿈 관련 경고 메시지만 숨기기

# Mac OS 환경
git config --global core.autocrlf input

 

※ crlf (줄 바꿈 방식)

  • crlf: Carriage Return + Line Feed (\r\n) - 윈도우
  • cr: Carriage Return (\r) - 고전 맥
  • lf: Line Feed(\n) - 맥

 

git config user.name # 등록한 유저 이름 출력
git config user.email # 등록한 유저 이메일 출력
# Git Confing 설정 확인하기
git config --list # 터미널에서 확인
git config --global -e # 기본 에디터에서 확인
  • git config --global -e 실행하면 에디터가 켜지고 터미널에서는 waiting 되는데, 에디터 창을 닫으면 터미널의 waiting이 끝난다.

 

# git init 명령으로 생성된 저장소의 기본 브랜치가 master일 때 main으로 브랜치명을 변경
git branch -m main

# git init 명령으로 Git 저장소를 초기화 시킬 때 브랜치가 main이 되도록 설정
git init -b main

# 로컬 환경에서 git init 명령을 통해 Git 저장소를 초기화하면 기본 브랜치가 main이 되도록 설정 
git config --global init.defaultBranch main

# 터미널에서 git log 보기 옵션을 less로 설정하기
git config --global core.pager "less -F -X"
  • git branch -m main과 git init -b main은 다음번에 git init 했을 때 여전히 기본 브랜치가 master로 생성되는 유지되는 일회성 코드들임!
  • git config --global init.defaultBranch main은 한 번만 설정하면 git init을 할 때마다 기본 브랜치가 main으로 설정된다!

| Git 명령어

- init, status, diff, add

git init # 저장소 생성
git status # 현재 상태 확인
git diff # 파일의 변경 내용 비교하기

git add <file> # 특정 파일 Staging Area에 추가
# 변경 내용 있는 모든 파일을 Staging Area애 추가하려면 파일명 대신 *나 .을 입력하면 된다.

  • 새로운 파일을 생성했을 때 EXPLORER 창을 보면 파일 명이 초록색으로 된 것과 동시에 U(Untracked)라고 되어있는데, 이것은 Git이 현재 관리하고 있지 않은 파일을 의미한다. 즉, 해당 파일이 Git의 버전 관리 목록에 포함되지 않았다는 것이다!
  • 현재 파일이 Working Directory에 있는지 Staging Area에 있는지 확인하기 위해 쓰는 명령어는 git status이다.
  • git status를 통해 확인하지 않고 VSCode의 'SOURCE CONTROL' 창으로 봤을 때, 'Changes'에 해당 파일이 있다면 그 파일은 Working Directory에 있는 것이다.

 

git add README.md # 파일의 변경 사항 Working Directory → Staging Area
git status
  •  add 되고 난 후, Source Control 창을 확인해 보면 Changes에 있던 READ.md 파일이 Staged Changes로 이동된 것을 확인할 수 있다.

  • 그리고 다시 git status를 입력해 보면 빨간색이던 게 초록색으로 바뀌었다.
  • 기존에 Staging area에 있던 파일 내용을 수정하면, 수정된 부분이 Changes(Working Directory)에 있는 것을 알 수 있고, add를 하면 수정된 부분도 Staging Area로 가게 된다.

-  commit

git commit -m "commit message" # -m 옵션은 커밋 메시지다.


- 모든 파일이 commit 되는 것이 아닌, Staging Area에 있던 파일들이 commit 되는 것이다.


- GUI에서는 Message창에 커밋 메시지 입력하고, Commit 버튼을 누르면 된다.		 
# 같은 의미의 명령어
git commit -a -m "commit message" # -a: add / -m: commit message
git commit -am "commit message"
  • 원래는 Working Directory에 있는 것을 바로 commit 하는 것은 불가능하다.
  • 무조건 Staging Area로 이동한 후(add 하는 것) commit 가능한데, git commit에서 -a 옵션을 사용하면 add 할 필요 없이 working directory에 있는 것을 바로 commit 시킬 수 있다.
  • 하지만 -a 옵션은 commit 했던 적이 있는 것만 사용할 수 있는 옵션이다!

정리해 보면, 아래와 같다.

📌 의미

  • -a: 수정된 tracked 파일들을 자동으로 add
  • -m: 커밋 메시지를 직접 작성

💡 결과

  • 이미 Git이 추적 중인 파일(tracked) 중 수정된 파일은 자동으로 add + commit 됨
  • 커밋 메시지에는 작업 내용 요약을 적음 (파일명 ❌)

⚠️ 주의사항

    • 새로 만든 파일(untracked)은 -a로 커밋 안 됨
      → 반드시 git add 파일명으로 추가 필요

- log

다른 파일들도 commit을 시킨 후, log를 확인해 보자!

git log # commit한 사용자 정보 및 날짜를 포함한 전체 로그 출력
git log --oneline # commit한 것 각각을 한줄 압축하여 로그 출력
git log --oneline --graph --all # log 한 줄 압축과 그래프 옵션 및 모든 브랜치를 볼 수 있도록 조회

git log --oneline 사용
git log --oneline --graph --all 사용

- rm --cached

git rm --cached README.md # Staging Area -> Working Directory
  • 위의 명령어를 입력하면 Staging Area 영역에 있던 파일을 Working Directory로 옮길 수 있다.

 
  • GUI로 Staging Area에서 Working Directory로 이동시키려면 위의 사진과 같이 - 버튼(Unstage Changes)을 누르면 손쉽게 이동할 수 있다.

이미 커밋된 적 있고, staging area에 있는 경우

  • 한 번도 커밋된 적 없는 것은 untracked 상태이고, 커밋된 적이 있던 것은 tracked 상태이기 때문에 Staging Area에서 Working directory로 이동시키는 명령어가 다르다.
  • git status를 입력했을 때, 커밋된 적이 없던 것은 터미널에 git rm --cached <file>이 뜨고, 커밋된 적이 있던 것은 위 사진처럼 git restore --staged <file>이 뜬다.
  • 하지만 GUI 상에서는 두 가지의 차이가 없다.

+ 위 두 가지 명령어(rm --cached, restore)의 차이가 아직 헷갈려서 따로 정리해 보았다! (링크)

- restore

git restore 파일명 # Working Directory → 마지막 commit 상태
# GUI에서는 Discard Changes

  • Working Directory에서 Restore을 시키는 것은 해당 파일이 마지막으로 commit 된 상태로 되돌아가는 것이다.
  • 즉, 현재 작업 중인 변경 사항이 모두 사라지고, 마지막 commit의 내용으로 파일이 재설정되는 것이기 때문에 신중하게 사용해야 한다❗

 

- branch

#브랜치 생성
git branch 브랜치명 # 새 브랜치 생성만 하고, 위치는 현재 브랜치로 유지함
git switch -c 브랜치명 # 새 브랜치 생성하면서, 그 브랜치로 위치 전환함

 

#브랜치 이동
git switch 브랜치명 # 요즘 사용
git checkout 브랜치명 # 이전 사용

# 브랜치를 만들고 바로 이동
git switch -c 브랜치명 # 요즘 사용
git checkout -b 브랜치명 # 이전 사용

# 브랜치 삭제
git branch -d 브랜치명
  • 브랜치 끼리 이동할 때는 원래는 checkout을 사용했었지만 이제는 switch를 사용한다. (이전 버전들 때문에 checkout도 아직 터미널에서 잘 작동한다..!)


- VSCode 창 왼쪽 하단에 브랜치를 클릭하면
오른쪽 사진과 같은 창이 뜨고,
해당 창에서 새로운 브랜치를 만들고
이동까지 바로 할 수 있다.

- merge

# merge (main 브랜치에서 실행)
git merge 브랜치명 # Fast-forward merge
git merge --abort # merge 삭제

 

▶ 만약 두 브랜치(main과 자식 브랜치)에서 같은 파일의 같은 위치를 수정하고 각각 커밋한 후 머지할 때 충돌이 발생한다면?

  • 충돌(Conflict)이 발생한 후 수동으로 해결하여 완료하는 merge는 3-way Merge (Non-Fast-forward Merge)라고 한다.
  • 두 브랜치의 분기점과 각자 최신의 커밋을 비교해 충돌을 감지하기 때문이다. 

 

① 아래와 같은 에러 내용이 뜰 것

Auto-merging [파일명]
CONFLICT (content): Merge conflict in [파일명]
Automatic merge failed; fix conflicts and then commit the result.

(git status로 충돌 파일이 무엇인지 확인할 수 있다.)

 

② 충돌 파일 예시

<<<<<<< HEAD        # 현재 브랜치(main)의 내용
main에서 수정한 내용
=======
자식브랜치에서 수정한 내용
>>>>>>> 자식브랜치  # 머지하려는 브랜치의 내용

 

③ 해결 방안 3가지

  1. main 브랜치 내용을 남기고 자식 브랜치 내용 삭제
  2. 자식 브랜치 내용 남기고 main 브랜치 내용 삭제
  3. 둘 다 통합해서 새로운 내용 작성(ex. 두 변경사항을 조합)

④ 충돌 마커 삭제

  • <<<<<<< , =======, >>>>>>>  라인을 전부 제거 후, 최종 코드만 남긴다.

⑤ 수정 완료 후, 저장

  • 파일 저장 후 git add 파일명으로 스테이징 한다.

⑥ 머지 완료

  • 모든 충돌 파일 수정하고, git add 했다면, commit으로 merge를 완료한다.
  • 만약 메시지 수정이 필요하다면, git commit -m "충돌 해결: [설명]"으로 작성하면 좋을 듯!

3-way Merge 수행 후 log

- checkout

git checkout HEAD~순서
git checkout HEAD~해시코드
  • 커밋 히스토리를 이동하고 싶을 때 쓰는 것이 checkout이다.
  • 커밋 메시지를 가리키는 시점으로 이동하는 것이다! (이동하고자 하는 시점의 해시코드나 순서를 사용할 수 있음)

 

원격 저장소(Github)와 로컬 저장소 연결

# 로컬에 존재하지 않는 repository의 경우
git clone "원격 저장소 url" # Git을 사용하여 원격 저장소(예: GitHub)에 있는 프로젝트를 로컬 컴퓨터로 복사하는 데 사용. 원격 저장소의 모든 파일, 이력 포함하여 복제

# 로컬에 존재하는 repository의 경우
# 깃허브와 연결하고자하는 깃으로 이동 후 아래의 명령어 실행
git remote add origin "깃허브 레포지터리 주소" # 현재 로컬 Git 저장소에 원격 저장소(예: GitHub)를 추가하는 것
git push -u origin main # 로컬 main 브랜치를 원격 저장소인 origin으로 푸시하는 것. -u 옵션은 로컬 브랜치와 원격 브랜치 간의 추적 관계 설정

#참고
# 첫번째 commit일 때
git push --set-upstream origin main

# 그 이후 commit들은 아래와 같이 사용하면 됨
# -u = --set-upstream
git push -u origin main # origin 이라는 주소를 가진 저장소에 main의 내용을 푸시

# 원격 저장소에서 변경한 것 로컬로 당겨오기
git pull
  • push = 내 컴퓨터(Git 로컬 저장소)의 변경사항을 GitHub(원격 저장소)로 보내는 것.
  • pull = GitHub(원격 저장소)의 최신 내용을 내 컴퓨터로 가져오는 것.
  • 한번 tracked 된 거는 그냥 git pull / push 하면 됨
  • untracked인 거는 무조건 처음에 --set-upstream을 해야 함. 

 

# origin 삭제 방법
git remote remove origin
git remote rm origin

# 삭제 되었는지 확인
git remote -v

# remote 다시 추가하고 싶다면?
git remote add origin https://github.com/your-id/your-repo.git
# 또는 깃허브에 로그인 된 VSCode에서 SOURCE CONTROL의 Publish Branch로 연결해도 됨

'멋쟁이사자처럼 > Git | Github' 카테고리의 다른 글

[멋사 프론트엔드 부트캠프 14기] Git 작업할 때, 주의해야 할 것은??  (0) 2025.05.13
[멋사 프론트엔드 부트캠프 14기] git add /git restore, git rm --cached의 차이  (0) 2025.04.24
[멋사 프론트엔드 부트캠프 14기] .gitignore  (0) 2025.04.24

티스토리툴바