개발 공부 일지/Git

Git

dev-hpk 2024. 9. 7. 19:45

Git

Git 은 분산형 버전 관리 시스템으로 소프트웨어 개발 과정에서 소스 코드의 변경 사항을 추적하고 관리하는 데 사용됩니다.

버전관리

과제나 업무를 할 때 최종본, 최종본_a, 최종본_a_1 처럼 수정을 거치면서 파일을 관리했던 경험이 있을 것입니다. 이처럼 파일의 변화를 시간에 따라 기록했다가 추후 특정 시점의 버전을 사용할 수 있도록 하는 행위를 버전 관리라고 합니다.

장점

각 파일을 이전 상태로 되돌릴 수 있다.

시간에 따라 수정 내용을 비교해 볼 수 있다.

파일에 문제가 있을 때 쉽게 복구할 수 있다.

파일을 누가 작성&수정 했는지 알 수 있다.

Git의 장점

여러 사람이 동시에 작업하는 병렬 개발이 가능하다.

작업자들끼리 소스 코드를 직접 주고 받을 필요가 없다.

인터넷이 연결되지 않은 곳에서도 개발 할 수 있다.

중앙 저장소의 데이터가 유실되어도 복구 할 수 있다.

Git의 기본 용어

Repository(저장소): 소스코드들이 저장되어 있는 물리적인 공간을 의미합니다. 저장소에는 로컬 저장소(Local Repository)와 원격저장소(Remote Repository) 2가지 종류가 있습니다.

Working Tree : 현재 파일 수정, 저장 등의 작업을 하는 디렉터리를 말합니다.

Head: 현재 작업중인 브랜치를 말합니다.

Snapshot: 특정 시점에서 파일, 폴더 또는 워크스페이스의 상태를 의미합니다.

Commit : 변경된 작업 과정들에 대한 점검을 마치고 저장소에 남기는 작업을 의미합니다.

Checkout : 특정 시점이나 branch의 소스 코드로 이동하는 것을 의미합니다. 이전 버전 작업을 불러오는데 많이 사용합니다.

Branch : Commit 단위로 구분된 소스 코드 타임라인에서 분기점을 의미합니다. Branch에서 작업을 완료하면, Merge 작업을 수행할 수 있습니다.

Merge : Branch와 Branch의 내용을 합치는 작업인 병합을 말합니다.

Git의 구조 및 동작 원리

Working Directory
사용자의 작업 공간으로써, 로컬 저장소에 접근할 수 있으며 실제 파일을 수정하거나 생성하는 공간이다. Working Directory 내의 파일들은
추적(tracked)/비추적(untracted) 상태로 구분된다.

Staging Area
Working Directory에서 제출된 추적(tracked) 상태의 파일들을 관리 및 임시로 저장하는 공간이다. Staging Area에서는 파일의 내용을 직접 가지고 있는 것이 아니라 커밋하려는 파일의 추적 상태 정보들만 기록한다. Staging Area 내의 파일들은
stage/unstage 상태로 구분된다.

Local Repository
내 PC에 위치한 git 설정된 디렉토리로 git 저장소를 생성했거나, 원격 저장소를 clone해 와서 내 PC에 존재하는 Git 저장소이다.

Remote Repository
로컬 repository와는 반대로 내 컴퓨터가 아닌 인터넷이나 네트워크에 있는 원본 저장소이다.

파일 상태

Untracked

파일이 Git에 의해서 그 변동 사항이 전혀 추적 되고 있지 않는 상태입니다.
파일을 새로 생성하고 그 파일을 한 번도 git add 해주지 않은 상태를 Untracked라고 합니다.

Tracked

파일이 Git에 의해 그 변동 사항이 추적 되고 있는 상태입니다.
Tracked 상태는 그 특성에 따라 3가지 상태로 나뉜다.
1. Staged
  
  staging area에 올라와 있는(commit이 가능한) 상태를 말합니다.
  Staged 상태가 되기 위해서는 git add 명령어를 사용해야 합니다.
1. Unmodified
  
  수정되지 않은(최신 커밋과 내용이 같은) 상태를 말합니다.
1. Modified
  
  수정된(최신 커밋과 내용이 다른) 상태를 말합니다.
  git add 명령어를 사용하면 staged 상태가 됩니다.

파일 상태 확인을 위한 명령어

git status

결과:

Git 명령어

기본 명령어
- init
  로컬 저장소에 git을 사용할 준비를 하는 과정입니다.
  
  현재 폴더에 .git이라는 폴더가 생성되며 해당 폴더에서 git 명령어를 사용할 수 있게 됩니다.
```
git init
```
- clone
  원격 저장소를 복제하여 로컬 저장소를 만듭니다.
```
git clone [레포지토리 주소]
```
  레포지토리 주소 확인: github의 원격 저장소에서 Code를 눌러 확인 가능
- add
  커밋하기 전 수정된 파일을 준비 시키는 명령어입니다.
  
  변경된 파일을 스테이징 영역에 추가합니다.
  - 특정 파일 스테이징 영역에 추가
```
git add [파일 | 디렉토리]
```
  - 현재 경로의 모든 파일 스테이징 영역에 추가
```
git add .
```
- commit
  스테이징 영역의 변경 사항을 커밋합니다.
  - 한 줄 메시지를 포함해 커밋
```
git commit -m "커밋 메시지"
```
  - 여러 줄 커밋 메시지를 포함해 커밋
```
git commit
```
- status
  작업 디렉토리와 스테이징 영역의 상태를 출력합니다.
```
git status
```
- log
  커밋 히스토리를 출려합니다.
```
git log
```
  커밋 하나당 한 줄씩 출력하려면
```
git log --pretty=oneline
```
- diff
  변경된 파일의 차이점을 보여줍니다.
```
git diff [커밋A_ID] [커밋B_ID]
```

브랜치 관련 명령어
- branch : 현재 브랜치 목록을 보여줍니다.
```
git branch
```
  브랜치 이름을 추가하면 새로운 브랜치를 생성합니다.
```
git branch [브랜치 이름]
```
  d 옵션을 추가하면 브랜치를 삭제합니다.
```
git branch -d [브랜치 이름]
```
- checkout : 지정한 브랜치로 이동합니다.
```
git checkout [브랜치 이름]
```
  b 옵션을 추가하면 새로운 브랜치를 생성하고 그 브랜치로 이동합니다.
```
git checkout -b [브랜치 이름]
```
- merge : 현재 브랜치에 다른 브랜치를 병합합니다.
```
git merge [브랜치 이름]
```
  브랜치 이름 대신 --abort 옵션을 주면 merge 작업을 취소하고 이전으로 돌아갑니다.
```
git merge --abort
```

원격 저장소 관련 명령어
- remote
  add를 사용하면 원격 레포지토리를 로컬 레포지토리와 연결합니다.
```
git remote add origin [원격 레포지토리 주소]
```
  v 옵션을 추가하면 현재 연결된 원격 저장소의 url을 확인합니다.
```
git remote -v
```
  update를 사용하면 원격 레포지토리의 모든 브랜치를 가져옵니다.
  (add origin은 브랜치를 모두 가져오지 않습니다)
```
git remote update
```
- fetch
  로컬 레포지토리에서 HEAD가 가리키는 브랜치의 upstream 브랜치로부터 최신 커밋들을 가져옵니다.
```
git fetch
```
- push : 로컬 레포지토리의 내용을 리모트 레포지토리에 올립니다.
```
git push
```
  로컬 레포지토리의 내용을 처음으로 리모트 레포지토리로 올리려면 다음 명령어를 사용합니다.
```
git push -u origin master
```
  or
```
git push --set-upstream origin master
```
- pull : 원격 저장소의 변경 사항을 로컬 저장소에 통합합니다.
```
git pull
```

유용한 명령어
- stash : 현재 작업하던 내용을 스택에 임시로 저장합니다.
```
git stash
```
  apply를 사용하면 가장 최근의 작업 내용을 Working Directory에 적용합니다.
```
git stash apply
```
  apply에 stash 이름을 추가하면 특정 커밋을 Working Directory에 적용합니다.
```
git stash apply [stash 이름]
```
  drop을 사용하면 스택 영역에 저장된 가장 최근의 작업 내용을 스택 영역에서 삭제합니다.
```
git stash drop
```
  drop에 stash 이름을 추가하면 스택 영역에 저장된 특정 작업 내용을 스택 영역에서 삭제합니다.
```
 git stash drop [stash 이름]
```
  pop을 사용하면 스택 영역에 저장된 가장 최근의 작업 내용을 Working Directory에 적용하고 스택 영역에서 삭제합니다.
```
git stash pop
```
  pop에 stash 이름을 추가하면 스택 영역에 저장된 특정 작업 내용을 Working Directory에 적용하고 스택 영역에서 삭제합니다.
```
git stash pop [stash 이름]
```
- cherry-pick : 특정 커밋의 내용을 현재 커밋에 반영합니다.
```
git cherry-pick [커밋 ID]
```
- reset : git reset [옵션] [커밋 ID] 형태로 사용합니다.
  - soft 옵션을 사용하면 HEAD가 특정 커밋을 가리키도록 이동 시킵니다.
```
 git reset --soft [커밋 ID]
```
  - mixed 옵션을 사용하면 staging area가 커밋 ID처럼 리셋 됩니다.
```
git reset --mixed [커밋 ID]
```
  - hard 옵션을 사용하면 working directory도 커밋 ID처럼 리셋 됩니다.
    hard 옵션을 사용하면 돌아간 커밋 이후의 변경 이력은 모두 삭제합니다.
```
git reset --hard [커밋 ID]
```
- revert : 특정 커밋의 작업을 취소하고 새로운 커밋을 생성합니다.
```
git revert [커밋 ID]
```
- rebase : base를 재설정한다는 의미로, 하나의 브랜치가 다른 브랜치에서 파생되서 나온 경우, 다른 브랜치에서 진행된 커밋을 다시 가져와서 base를 재설정하는 것입니다.
  - 장점:
    프로젝트 히스토리가 완전히 선형으로 변형되어 브랜치를 따로 추적하고 확인하며 기능확인을 하지 않고 처음부터 끝까지 선형적으로 프로젝트 히스토리를 따라갈 수 있습니다.
  MERGE
  
  REBASE
  
  위 사진처럼 rebase를 사용하면 커밋 이력이 깔끔해진다는 이점이 있지만 유의할 점도 있기 때문에 merge와 rebase를 적절히 사용해야 합니다.
  파생된 브랜치에서 이미 새로운 커밋이 발생하고 작업이 기록되고 있는데 이전 기준 브랜치로 base를 변경해버리면 파생 브랜치로 작업하고 있던 작업자들의 커밋 히스토리가 변경되어 버리기 때문입니다. 각 작업자들은 자신의 커밋을 다시 반영하거나 재작업을 해야 할 수도 있습니다. 따라서 혼자 작업하는 브랜치나 작업하는 사람이 적어 문제 상황이 발생할 확률이 적은 경우에만 주의 깊게 사용해야 합니다.