Git 브랜치 다루기

git branch => 전체 브랜치 리스트를 보여줌

 

git branch 브랜치이름 => 브랜치 생성

git branch -d 브랜치이름 => 브랜치 삭제

 

git checkout 브랜치 이름 => 브랜치 이동 

git checkout  -b 브랜치이름 => 새로운 브랜치를 생성함과 동시에 이동 

https://blog.outsider.ne.kr/1505

새 버전에 맞게 git checkout 대신 switch/restore 사용하기 :: Outsider's Dev Story

checkout 이 두 가지 커맨드 switch/restore 로 세분화? 구분? 되었다고 한다 

git switch -c 브랜치 이름 <=> git checkout -b 브랜치 이름 

뒤에 커밋해시를 붙여주면 해당 위치에 브랜치가 생김

---

브랜치 merge

두 가지 버전(브랜치)로 프로젝트를 관리한다고 가정, 

한쪽(A) 브랜치에서 파일 수정 후 add, commit 

다른(B) 브랜치에도 동일한 수정이 필요한 경우

B로 checkout 한 뒤에

git merge master => 현재 위치 B 브랜치에 A 브랜치를 합친다

 

conflict 발생 시 !

1. 충돌한 파일 연다

2. 머지의 결과가 되었으면 하는 모습대로 코드를 수정

3. 커밋하면 머지가 완료됨

또는 merge 취소 (머지를 시도하기 이전 모습으로)

git merge --abort

 

이해가 안되는 시점..

Free version        : A - B - C - D - 1 - 2 - 3 커밋

Premium version : A - B - C - D - X - W - Z 커밋

이 상태에서 Free ver.에 있는 모든 기능이 Premium ver.에도 있어야 한다고 한다

 Free-> Premium 으로 merge 하면?

Free version        : A - B - C - D - 1 - 2 - 3 

Premium version : A - B - C - D - X - W - Z- 1 - 2 -3 이렇게 되는건가?

 

: 마스터 브랜치와 프리미엄 브랜치가 분기된 이후로 프리미엄 브랜치에 누적되었던 커밋들의 합이 마스터 브랜치에 머지됨

코드잇 강의

깃헙에서 리모트 레포지토리 만들고 

로컬 레포지토리 내용을 리모트 레포지토리로 보내기 위한 커맨드

git remote add origin https://github.com/ ~~

remote: 리모트 레포지토리 관련 커맨드 

url 해당 주소를 

origin 이라는 이름으로 (Git에서는 리모트 레포지토리를 최초로 추가할 때 origin이라는 이름으로 가리키는 것이 관례)

add: 새로운 리모트 레포지토리를 등록하겠다

 

git push -u origin master

현재 로컬 레포지토리에 있는 master 브랜치의 내용(=master 브랜치와 관련된 모든 커밋들)을 

origin 이라는 리모트 레포지토리로 보낸다

-u : --set-upstream 옵션

=> 로컬 레포지토리에 있는 master 브랜치가 origin에 있는 master 브랜치를 tracking 하는것으로 설정 된다

맨 처음 푸시 할때 트래킹 해주기

 

tracking이란 : 로컬 레포지토리의 한 브랜치가 리모트 레포지토리의 한 브랜치와 연결되어 그것을 계속 바라보는 상태가 되는것 -> tracking connection 이라고 한다

=> 로컬에서 push /pull 할때 자동으로 리모트의 master 브랜치 대상으로 동작한다

---

HEAD 와 branch 의 관계?

branch : 코드를 관리하는 하나의 흐름 = 어떤 커밋을 가리키는 존재 = 포인터

HEAD : 커밋을 가리키는 존재 = 포인터 .... 이지만 사실은 branch 를 가리킨다 -> 커밋을 간접적으로 가리킴

checkout : HEAD 를 특정 branch 를 가리키도록 함

 

checkout 을 통해 HEAD 가 branch가 아닌 커밋을 직접 가리키도록 할 수도 있음 = Datached HEAD

이 상태에서 git branch 새로운브랜치 를 생성후 check 새로운브랜치 하면 다시 브랜치를 가르키는 HEAD 가 됨

---

git reset :

1) 과거의 커밋으로 reset 을 해도 그 이후의 커밋이 삭제되는건 아님, 계속 남아있다 

2) 과거의 커밋 뿐 아니라 현재 HEAD 가 가리키는 커밋 이후의 커밋으로도 할 수 있다

---

Fast-forward 머지 / 3-way 머지

 

출처 : 코드잇

3-way merge는 base에서 변화가 발생한 것을 우선 채택

---

로컬 레포지토리에서 코드 수정 후 add, commit 하는 동안

리모트 레포지토리에 (다른 개발자에 의해.. ) 수정된 커밋이 존재한다면?

내가 작성한 건 push 되지않고 reject 당함 

 

그렇다면 git pull 을 하면? conflict 가 발생할 수 있음 

git pull은 수정된 내용을 가지고와서 현재 브랜치에 merge 하는것까지 포함하기때문에.

-> conflict 해결해주면됨 

다시 add commit -> git pull 완료 

 -> 다시 git push 

---

git fetch : pull과 달리 머지하지않고 가져오기만 함 

git diff 로 두 커밋간의 차이 확인 & 브랜치간의 차이 확인 

git diff premium origin/premium

(로컬 레포지토리 입장에서 리모트에 있는 premium branch를 표현)

확인 후 -> git merge 

---

git blame +파일명 : 어떤 파일의 특정 코드를 작성한 사람(커밋아이디)을 알려줌 

-> git show +커밋아이디 로 작성자 확인

---

리모트 레포지토리에 푸시한 커밋을 취소하려면?

git revert +커밋아이디 : 특정 커밋에서 했던 작업을 그 이전으로 되돌리는 커밋을 새로 생성 

-> 해당 커밋을 취소하고 다시 commit 진행 

-> git push 

 

직전 커밋으로 restore 하고 push 하려고하면? 

리모트 레포지토리에 이미 최신 커밋이 있기때문에 push가 안됨 

revert 는 하나의 커밋이 새로 생성되는거기때문에 push가 됨 

---

git revert 커밋아이디1 .. 커밋아이디2 

-> 커밋아이디1 다음 커밋부터~ 커밋아이디2까지 revert 됨 

(각각에 대한 revert commit 생성된다) 

 

헷갈리는 부분.. 

https://about-tech.tistory.com/250

[Git] 되돌리기 명령어 (restore, reset, clean 사용법)