Git 기본 개념

▷ upstream, origin 개념 이해
▷ add, commit 개념 이해
▷ merge, rebase, cherry pick 개념 이해

[upstream, origin 개념 이해]

upstream : 상류

origin : 원천

→ 모두 상대적인 개념!

origin -------------------------- local
 push / pull

git remote add origin 원격저장소주소

→ remote : 원격으로 관리하겠다.

git push -u origin main

→ 오리진 저장소의 main 브런치에 푸시하겠다

→ -u 의 의미 = --set-upstream = 상하관계 성립하는 과정 (ex. 내 깃헙과 원격 저장소와의 관계 성립)

→ 최초에만 -u 사용(안하면 push 안됨)

 

1 = 공통의 remote 저장소

2 = 개인(나)의 원천저장소

3 = 개인(나)의 local 저장소

 

1에 있는 코드를 fork 해서 여러 개의 origin(2)를 만들 수 있다. 

2에서도 가져와서 여러개의 3을 만들 수 있다.

→  1-2-3 을 거치면서 여러개의 갈래로 갈라질 수 있다. 

 

(+) git clone 하면 자동으로 상하관계 설정된다.

---

[add, commit, push 명령어 이해]

현재 디렉토리(ex.aa)에서 git init을 입력하면, 현재 디렉토리(aa)가 로컬저장소가 된다? [X]

 

→ 터미널에 입력해보면 aa/.git/ 안의 빈 깃 저장소를 초기화했습니다. 라는 설명이 뜬다.

즉, 현재 디렉토리(aa)는 그냥 작업하는 공간이고, 로컬저장소는 현재 디렉토리(aa) 안의 git 디렉토리(.aa/.git)가 된다.

 

 

blob, commit, tree, tag, branch 중 Git의 객체가 아닌 것은? [ branch ]
→ branch는 그냥 참조이다

 

→ blob = 파일

→ commit = 저장단위, tree + blob + 메타정보

→ tree = Blob을 묶어서 관리( 디렉토리 구조와 유사)

→ tag = 커밋에 대한 참조이지만 설명이 추가되는 객체

 

(+)

commit  =  작업 디렉토리 스냅샷, 세이브 포인트

따라서 커밋 객체에는 돌아가기 위한 정보들이 포함되어야한다.

---

add, commit 명령어를 구분한 이유? 각 명령어 실행 시 생성되는 객체가 다르다

add 했을 때 생성되는 객체 →  index, object 파일(blob)

commit 했을 때 생성되는 객체 → tree, commit 객체

 

→  add 하면 index, object 파일(blob)이 추가되며 git의 관리대상이 된다. ex. git add a.txt( a 텍스트 파일을 git이 인식)

→ tree객체는 blob의 정보(구조..)들을 담고 있는 객체, 그 tree객체를 담고 있는  commit 객체가 존재함.

→ 이러한 과정을 통해 객체들의 상하관계가 생성되며, 객체 생성의 시점이 다르다보니 명령어를 구분하게 된 것.

→ add, commit은 상하관계를 관리하는 입장에서 살펴보면 된다. 

 

파일의 내용을 수정하고 커밋하면 Git은 공간효율을 위해 변경사항만 저장한다? [X]
깃은 통째로 저장한다.

 

따라서 최신상태는 가장 마지막 commit 한 상태  (마지막 상태의 blob) 이다.

---

 

[Merge, Rebase, Cherry-pick 개념 이해]

[merge]

- 깃은 서로다른 작업을 하기위한 별도의 공간(브랜치 branch) 생성이 가능한데,

브랜치에서 기능구현이 완료되는 경우, 해당기능을 main 브랜치에 merge 할 수 있다.

즉, 두 브랜치를 합치는 과정!

 

fast-forward

: 가리키고 있던 커밋을 머지할 브랜치의 커밋으로 이동하는 것.

: base 가 같을 때 사용됨.

git merge test1 
 → test1 = 기능구현한 브랜치
동작 결과 : Fast-forward

 

 

3-way-merge

: ex. 기능 브랜치에 upstream의 main 브랜치에 있는 커밋들을 합쳐야하는 상황

git merge upstream/main

 

 

conflict

upstream 의 메인 브랜치의 코드와 기능구현한 브랜치 코드가 충돌났을 때

 

:merge 할 때 base 가 다르면 merge commit 을 생성하여 auto merge 한다.

단, conflict 발생 시, 개발자가 직접 처리.

 

Pull Request 의 머지 종류

1. Create merge commit

2. Squash and merge

3. Rebase and merge

 

 

[rebase]

: 현재 branch의 base를 재설정 하는 것

→ rebase 전 후의 commit 메시지의 id 가 달라짐( 복사되어서 새로 생성됨 )

 

[cherry-pick]

다른 브랜치에 있는 커밋을 선택적으로 내 브랜치로 가져오는 것.

develop 브랜치에 있는 기능2만 main 브랜치에 커밋하고 싶다( 기능 3이 아직 미완성)

$ git checkout main
$ git checkout -b aaa
$ cherry-pick 319c319( = commit id)
$ git push origin aaa

→ 한 개의 커밋만 가져오고 싶을 때  ▶  git cherry-pick 커밋아이디

→ 여러 개의 커밋 가져오고 싶다면 공백으로 구분 ▶ git cherry-pick 커밋아이디1  커밋아이디2  커밋아이디3

→ 연속된 커밋 가져오고 싶다면 ..으로 연결  ▶  git cherry-pick 커밋아이디1.. 커밋아이디5

 

충돌conflict 발생한다면?

1. 코드 수정

2. git add .

3. git cherry-pick --continue

---

 

 

 

REFERENCE

https://www.youtube.com/watch?v=b72mDco4g78