git 유용한 명령어들

요즘 갈 방향을 잃은 느낌이라 주의 환기 및 내가 주로 쓰던 명령어들을 복습겸 적어볼려고 한다.

git reset 

깃 공간을 크게 3가지로 나눈다면

 

1. Working Directory (create, update, Delete해서 작업한 파일이 반영되어 있는 디렉토리)

2. Staging Area(git add후 곧 commit 하기 이전의 디렉토리)

3. Git Directory(staging Area에 있는 작업이 commit되어 반영된 공간)

 

이라 할 수 있다.

이때 작업을 하다보면 각 공간(1->2, 2->3)에 잘못 반영될때도 있는데 이때 유용한 명령어가 바로 git reset이다.

 

git reset때 지워지는 영역

git reset은 크게 3가지이다.

 

사용 ex) git reset --soft HEAD^1(바로 이전 커밋(head)에 반영됨)

1. git reset --soft

 

commit을 잘못 반영했을때 Staging Area로 되돌릴 수 있는 명령어이다.

주로 commit명에 오타를 냈을때 많이 사용했다.

 

2. git reset --mixed

git reset의 default

해당 커밋의 repository~staging area의 영역에 있는 코드들을 전부 working directory에 반영한다.

(git add 이전 상태로 되돌린다)

 

주로 이전 커밋으로 돌아가서 staging area에 반영할 코드들을 기능별로(커밋을 나누고 싶을때)쪼개 commit할때 사용했다.

 

3. git reset --hard

작업을 아예 rollback할때 사용한다.

 

구현할때 어떤 이론을 세우고 작업을 했는데 내 이론이 틀렸을때 주로 사용했다.

 

git reflog

 

이걸 사용한경우는 손에 꼽히기는 한데 git reset --hard나 git 작업을 하다 잘못했을경우 롤백할 수 있는 매우 유용한 기능을 제공한다.

 

git rebase/git reset 등으로 커밋 이력이 삭제되었을때 git reflog를 하면 볼 수 있다

 

git cherry-pick 

 

다른 브랜치에 있는 commit을 선택적으로 반영할때 사용된다.

깃은 diff 가 아니라 각 커밋이 스냅샷이긴 한데 체리픽을 할때는 diff만 반영되는거(커밋 하나의 변경점) 같다.

 

tmi로 경험적으로 깨달은건데(틀릴수도 있음)

local에서 작업할때 git fetch 로 remote repository의 브랜치들을 가져와 있으면 local branch에 git cherry-pick 적용이 된다는 점이다. 

 

git rebase/merge/squash and merge

 

merge

 

왼쪽 3-way merge, 오른쪽 fast-forward merge

1. 3-way merge : 분기점이 있는경우 3-way merge를 해서 브랜치 두개를 합친다. (중간에 매개 commit인 merge commit이 하나 남는다)

2. fast-forward merge : 현 커밋보다 앞선 커밋들이 있는경우 fast-forward merge를 해서 앞선 커밋들을 충돌없이 따라간다.

그리고 commit id 는 그대로 남는것으로 알고 있다.

 

squash and merge

 

두개의 브랜치를 합칠때 합쳐지는 대상이 여러개의 커밋이라도 '하나의 커밋'으로 합쳐져서 반영되게 된다.

ex) squarsh and merge를 했을경우

그리고 그 커밋들은 커밋 내역에 합쳐져서 보이게 된다. 

 

rebase

 

일종의 되감기인데 두개의 브랜치가 한 줄로 이어지게 된다.

커밋 내역을 깔끔하게 보여줘서 rebase 팬들도 은근히 많이 있더라..

 

예시로

 

같은 부모 0 에서 시작한 1-2-3 이라는 A branch와

a-b-c라는 B 브랜치가 있다면

rebase 시 1-2-3-a-b-c 이런식으로 한줄로 된다.

 

그리고 Merge는 Commit ID가 보존되고, Rebase는 새로운 Commit이 생성되므로 Commit ID가 바뀐다

https://learngitbranching.js.org/?locale=ko 에서 테스트해보자. 

C3에서 나온 rebase branch(C4, C5)에서 C8을 rebase 했더니 C4', C5'로 각각 새로운 commit Id가 생성된것을 확인 가능하다. 

 

C3에서 나온 mege branch(C6, C7)에서 C9를 merge 하면 C10 가 새로 생기고(merge commit) 

C9의 commit Id가 바뀌지 않고 그대로 이어진것을 확인 가능하다.

git log --graph

이런식으로.. cui에서 그래프 형태로 보여주게 된다

협업할때 이걸 써서 브랜치 현황을 보여주면 소스트리를 쓰는 팀원이 아주 좋아죽는다

 

소스트리같은 소프트웨어로 브랜치를 더 깔끔하게 보는 방법이 있으니

이런거 쓰지말고 착한 깃린이 여러분들은 이걸 쓰세여ㅠㅠ

 

소스트리 링크) https://www.sourcetreeapp.com/

Sourcetree | Free Git GUI for Mac and Windows

 

git push origin main -f 

 

reference

 

git reset

 

https://opentutorials.org/module/4032/24533

git reset --hard vs --mixed vs --soft - GIT4 - Reset & Revert

 

https://im-developer.tistory.com/182

[Git] Merge 이해하기 (Merge / Squash and Merge / Rebase and Merge)

 

https://stackoverflow.com/questions/34019195/git-pull-doesn-t-fast-forward-merge-even-though-there-are-no-conflicts

Git pull doesn’t fast-forward merge, even though there are no conflicts

https://www.tuwlab.com/ece/22218

[GIT] 병합하고 Commit 재정렬하기: cherry-pick, rebase, merge - ECE - TUWLAB