[Git] git 기본

« 2025/01 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

Git이란 무엇인가?

분산형 버전 관리 시스템(Version Control System) 의 한 종류.
버전관리 예시

프로젝트의 수정 내용으르 복사, 백업, 저장하는 것을 빠르게 도와주는 도구가 git

장점

버전 관리

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

프로젝트를 통째로 이전 상태로 되돌릴 수 있다.

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

누가 문제를 일으켰는지 추적할 수 있다.

파일을 잃어버리거나 잘못 고쳤을 때에도 쉽게 복구할 수 있다.

팀 프로젝트가 아닌 개인 프로젝트에서도 버전 관리가 용이하고 프로그램이나 패치를 배포하는 과정도 간단해진다.

협업

소스 코드를 주고받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능하다.

분산 버전 관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있고, 나의 저장소가 날라가도 원상복구 할 수 있다.

Git Area에 대한 용어

Working Tree (Working Directory)

작업자의 현재 시점. 파일 수정, 저장 등 내가 작업하고 있는 프로젝트의 디렉토리.

Staging Area

// staging area에 추가 
git add <파일 이름>
// staging area에 전부 추가
git add .
// staging area에서 제거 
git restore --staged <파일 이름>

commit 하기 전에 변경 내역이 저장되는 장소

변경 내역 중 commit으로 등록하기 위해 선별하는 것을 staging, 제외하는 것을 unStaging이라고 한다.

Repository *

commit한 파일들이 저장되는 장소. git은 크게 2종류의 저장소 (원격 저장소와 로컬 저장소) 를 제공한다.

원격 저장소(Remote Repository): 파일이 원격 저장소 전용 서버에서 관리되며, 여러사람이 함께 공유하기 위한 저장소.

로컬 저장소(Local Repository): 내 PC 안에 파일이 저장되는 개인 전용 저장소.

Git 에서 사용하는 용어

SnapShot

특정 시점에서 파일, 폴더, 또는 워크 스페이스의 상태

스냅샷을 통해 어떤 파일에 어떤 내용이 기록되어 있는지, 폴더 구조는 어떠한지 등 저장소의 모든 정보를 확인할 수 있으며, Commit을 통해 스냅샷을 저장한다.

Commit *

// 변경된 파일을 스테이징 하는 명령어
git add . 
// 스테이징과 커밋 메세지를 한번에 추가하여 커밋
git commit -am "first commit"

파일을 수정하게 되면 해당 변경 이력은 staging area에 올라간다.

commit은 staging area에 올라간 현재 작업 상태를 확정하고 저장소에 저장하는 작업.

Push *

// push 명령어, -u는 현재의 브랜치를 자동으로 origin의 해당 브랜치에 연결하겠다는 뜻
git push -u <저장소명> <브랜치명>
// -u 로 연결 후에는 다음과 같이 쓸 수 있다.
git push

현재 내 로컬 저장소에서 작업한 내용을 원격 저장소에 반영하는 것.

협업시에 Push 를 해야 다른 사람들이 내 코드를 확인할 수 있다.

Pull *

git pull

원격 저장소에서 변경된 내용들을 내 로컬 저장소에 반영하는 것.

pull은 해당 프로젝트에서 변경된 사항들만 다운 받는다.

Branch *

// 브랜치 목록 확인
git branch
// 새 브랜치 생성
git branch <브랜치명>
// 브랜치 이동 
git switch <브랜치명>
// 브랜치 삭제 
git branch -d <브랜치명>

특정 커밋이 분기되는 포인터. 여러 명이 같은 코드를 공유하며 협업하는 상황에서 각 개발자들이 개발을 진행하고 있는 환경 또는 흐름을 말한다.

Merge

// feature 브랜치를 main 브랜치에 병합하는 경우
git switch main 
git merge feature 
// 또는 다음과 같이 한줄로 표현 가능
git merge main feature

나뉘어진 Branch를 다시 하나의 Branch로 합치는 것을 말한다.

가장 오류가 많이 발생하는 과정 → 자주 발생하는 케이스에서 확인

다양한 merge 전략
- merge
  merge
  merge 후 커밋 내역
  - 일반적으로 많이 사용되는 병합이며, 커밋이력을 모두 남길 때에 사용.
  - 최종적으로 병합을 위한 커밋이 추가된다.
- squash & merge
```
git merge --squash <브랜치명> 
```
  Squash & Merge
  Squash & Merge 후 커밋 내역
  - 여러개의 커밋을 하나로 합쳐 Squash 한 새로운 커밋을 Base 브랜치에 추가하는 방식.
  - squash 하기 되면 모든 커밋 이력이 하나의 커밋으로 합쳐지며 사라진다는 것에 주의
- rebase
```
git rebase <브랜치명> 
```
  rebase
  rebase 후 커밋 내역
  - 브랜치의 base를 다른 브랜치의 최신 커밋으로 옮기는 작업.
  - 불필요한 병합 커밋 히스토리가 생기지 않고, main 브랜치에서 작업의 내용을 명확하게 확인할 수 있다는 장점이 있다.
  - 협업 시에 main 브랜치에서 절대 사용하면 안된다. → 다른 사람의 분기가 되는 기준 브랜치를 변화시키기 때문에 아래와 같은 혼란스러운 일이 발생.
  main에 rebase를 할 때 발생할 수 있는 문제

CheckOut

branch 간의 이동을 체크아웃이라고 표현한다.

현재 워킹 디렉토리에 commit하지 않은 변경사항이 있다면 branch를 체크아웃 할 수 없다.

이전에는 checkout 명령을 사용했지만 이제는 switch과 restore로 분리

변경된 명령어

Head

현재 작업하고 있는 위치.

log

// 히스토리 내역 확인
git log

HEAD, commit 내역 등을 확인하고 싶을 때에 사용하는 명령어

명령어 옵션

// 히스토리 조금 더 예쁘게
git log --graph
// 커밋 해쉬값 7자리까지만
git log --graph --abbrev-commit
// 커밋 해쉬 번호와 메세지만 
git log --graph  --abbrev-commit --pretty=oneline

status

git status

수정된 파일의 목록들을 확인하는 명령어

fetch

git fetch

원격 저장소에 업데이트 된 내용이 있는지 확인한다.

pull은 변경된 내용을 확인하고 병합한다면, fetch는 확인만 하고 병합은 하지 않는다.

reset

// 바로 전 commit으로 돌아갈때 
git reset HEAD^
// 여러개의 commit으로 되돌릴때 
git reset HEAD~<돌아갈 커밋 수>
// 특정 commit으로 되돌아갈때
git reset --옵션 <돌아갈 커밋 해시>

해당 커밋을 제거하고 이전 커밋으로 돌아간다.

원격 저장소(origin)에 commit이 있는 상태로, 로컬 저장소에서 reset 후 push하려고 하면 에러가 뜬다. → -- force옵션으로 원격 저장소의 히스토리를 강제로 덮어쓸 수 있지만 협업시에는 하면 안되는 행동이다.
리셋을 하면 안되는 이유 설명을 위한 예시 그림

reset을 사용하는 경우는 1. 원격 저장소에 push하기 전 2. 혼자만 사용하는 브랜치인 경우 만으로 국한된다.

명령어 옵션

// 돌아간 이후 변경 이력을 모두 삭제
git reset --hard <커밋 해쉬 번호>
// 변경 이력은 모두 삭제하지만 코드들은 unstage 상태로 코드에 남아있음
git reset --mixed <커밋 해쉬 번호>
// 변경 이력은 모두 삭제하지만 코드들은 stage 상태로 코드에 남아있음
git reset --soft <커밋 해쉬 번호>

revert

git revert <취소할 커밋 해시>

현재 commit은 그대로 두고 돌아가려는 commit을 추가한다. → 히스토리가 남는다.

여러개의 commit을 되돌리고 싶으면 최근 commit부터 순차적으로 revert 해야한다.

협업시에 무슨 문제가 있었고 왜 돌아갔는지 등의 기록이 가능하다는 장점이 있으며, 충돌을 최소화 할 수 있다.

stash

// stash에 저장 
git stash 
// 가장 최근 저장한 stash를 불러온다
git stash pop

작업 내용을 저장하고 싶은데 커밋하기는 싫은 상황에 사용하는 명령어. 변경 사항을 스택 형태로 임시 저장한다.

명령어 옵션

// 저장된 stash 목록 확인
git stash list
// 특정 번호의 stash 불러오기 
git stash apply <stash 번호>
// 특정 번호의 stash 파일 제거
git stash drop <stash 번호> 
// 저장한 모든 stash 제거
git stash clear

cherry-pick

// 가져올 커밋들 체리픽
git cherry-pick C2 C4
// 연속적인 커밋인 경우
git cherry-pick C2..C4

다른 브랜치에 있는 커밋을 선택하여 내 브랜치에 적용시킬 때 사용하는 명령어.

명령어 옵션

// 충돌날 경우 충돌 해결 후 해당 커맨드 작성
git add <충돌난 파일 경로>
git cherry-pick --continue 
// 충돌나서 포기하고 싶다면 
git cherry-pick -abort

Github연동하는 법

git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin <원격저장소 주소>
git push -u origin main

원격저장소 관련 명령어

// 원격저장소 url 확인
git remote -v 
// 새 원격저장소 추가 
git remote add <원격저장소 이름> <원격저장소 url>
// 기존 원격저장소 제거
git remote remove <원격저장소 이름>
// 원격저장소 url 변경
git remote set-url <원격저장소 이름> <원격저장소 url>

Git 을 통해 효율적인 작업을 위해 만들어진 방법론.

각자 개발 환경에 따라 수정하고 변형해서 사용할 수 있음.

master, develop 브랜치는 사라지지 않는 기본 브랜치이며, 나머지는 편의에 따라 만들고 사라질 수 있음.

들어가기 전 숙지해야 할 용어 설명

Fork

다른 사람이 만든 원본 저장소를 그대로 복사해 내 계정의 원격 저장소로 가져오는 것.

내 원격 저장소로 가져오더라도 해당 저장소는 원본 저장소와 연결되어 있다. → 원본 저장소에 새로운 로그가 추가된 경우 fetch나 rebase를 통해 fork된 저장소로 가져올 수 있다.

Clone

git clone <원격저장소 주소>

원격 저장소에 있는 프로젝트를 로컬 저장소로 복사해온다.

권한이 없는 경우, 원본 저장소의 로그를 볼 수 없고 push도 할 수 없다.

PullRequest(Merge reauest)

Github에서는 첫 행동이 pull이므로 PullRequest, Gitlab에서는 최종 행동이 merge이므로 MergeRequest라고 부른다.

Markdown 형태로 PR 형식을 미리 만들어둘수 있다.

장점 1. 직접 머지하지 않기 때문에 다른 사람의 코드와 커밋을 자세히 볼 수 있어 코드리뷰에 용이하다. 2.CI/CD와 같은 테스트 도구를 사용해 PR에 대한 테스트를 진행한 후 main에 머지할 수 있다. 3. 어떻게 다른 사람에게 내 코드를 리뷰해야 편 한지 살펴 볼 수 있다.

단점 1.PR 수락 & merge에 권한을 가진 사람이 부재중일 경우 작업 처리가 느려짐 → Fork 하지 않고 원본 저장소를 clone하여 매번 새로운 브랜치를 만들고, PR 한다.

Master Branch

실제 제품으로 배포하는 브랜치

Develop Branch

다음 출시 버전을 개발하는 브랜치로 개발자들이 각자 작업한 기능들을 merge 하는 브랜치

Feature Branch

단위 기능을 개발하는 브랜치

기능 개발이 완료되면 Develop Branch에 merge 후에 제거한다.

Release Branch

Master Branch로 보내 배포하기 전에 QA를 하기 위한 브랜치

Hotfix Branch

Master branch로 보냈는데 버그가 생겼을 때에 긴급 수정하는 브랜치

각 브랜치에 따른 merge 전략

feature → develop
- squash & merge: feature에서 기능 개발을 위한 지저분한 커밋 내용을 하나로 묶어 develop에 병합하면, 최종적으로 develop에는 기능 단위로 커밋이 추가되도록 정리할 수 있다.

develop → master
- rebase : squash하면 커밋 이력이 다 사라져 롤백이 불가, 그리고 master에 merge 커밋을 남길 필요가 없으므로 rebase가 적합하다.

Conflict

해결 방법
- <<<<<< HEAD는 현재 내가 작업하고 있던 상태의 코드
- >>>>>> <브랜치 이름> 은 merge로 병합하려고 한 코드
- 해당 코드들을 보고 수정한 후에 staging에 올리고 commit

버전 되돌리기

파일 전체를 이전 버전으로
- reset, revert
- 특정 commit 버전으로 돌아갈 경우 : git switch --detach <커밋 번호>

특정 파일만 이전 버전으로

// 특정 파일만 되돌리기
git restore <파일 이름>
// 스테이징 된 파일 내리기
git restore --staged <파일 이름>

Commit 메세지 변경 or Commit 취소

해결 방법

// 가장 최근의 커밋 메세지 변경 
git commit --amend
// 여러 커밋 메세지를 수정하고 싶을 때에 
git rebase -i HEAD~<수정할 커밋 메세지 수>
// push한 커밋 메세지를 수정하고 싶을 때에
git push --force <브랜치이름>

다른 브랜치에서 작업했을 때

해결 방법
- git stash 를 사용하여 작업하던 코드들을 stash에 저장하고, 작업 브랜치로 이동하여 pop
- 혹은 rebase를 통해 작업하는 코드의 base를 옮겨 해결할 수도 있음.

Git pull 전략

내가 작업한 코드의 commit이 있고, 협업자가 원격 저장소의 base에 작업한 내용을 이미 push 했을 때에 이 코드를 어떻게 pull 할지 결정하는 내용.

해결 방법
1. git config pull.rebase fase : 원격 저장소의 커밋을 가져와 merge - merge이기 때문에 머지 커밋이 하나 증가한 것을 확인할 수 있음.
2.git config pull.rebase true : pull 로 가져와야 할 코드를 앞에 배치(rebase)하고, 그 뒤에 커밋을 달음
1. git config pull.ff only : fast-forward 방식의 pull 만 허용한다.