알아두어야 할 git 명령어 (rebase 관련)

git rebase flow

git swtich main 

git fetch

git pull origin main

git switch (개인 브랜치)

git rebase -i main

각각 명령어 살펴보기

1. git swtich main

https://blog.outsider.ne.kr/1505 블로그의 내용을 참고하였습니다.

• [checkout](https://git-scm.com/docs/git-checkout): Switch branches or restore working tree files
• [switch](https://git-scm.com/docs/git-switch): Switch branches
• [restore](https://git-scm.com/docs/git-restore): Restore working tree files

내용을 알아보니, checkout이라는 명령어가 커버하는 범위가 넓어짐에 따라, switch 명령어와 restore 명령어를 적합한 절차에 맞게 사용하라는 내용.

• git checkout -b <BRANCH_NAME> : 알아두자. 브랜치를 만듦과 동시에 바로 변경이 가능하다. switch 명령어를 사용하면, git switch -c <BRANCH_NAME> 이라고 한다.
• git switch -c <BRANCH_NAME> 브랜치를 만들고 싶은 커밋 시기 : 뒤에 커밋 번호를 붙여주기

git restore라는 명령어도 알아두자. 위의 적어둔 블로그의 내용으로 대체한다.

$ git restore README.md

git add를 통해서 수정 내용을 stage에 이미 넣었을 때 이를 다시 빼려면 git reset HEAD README.md를 사용했어야 했는데 이 부분도 restore로 들어왔다. 수정사항을 빼고 조작할 때 모두 restore로 통일되어서 사용하기도 쉬울 테고 이해하기도 좋다.

$ git restore --staged README.md

1. git fetch

https://backlog.com/git-tutorial/kr/stepup/stepup3_2.html 블로그의 내용을 참고하였습니다.

fetch란, 원격 저장소의 데이터를 로컬에 가져오기만 한다는 명령어.

pull을 실행하면 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행하게 되는데, 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용할 수 있다고 한다.

이렇게 fetch 후 merge 를 수행하면, pull 명령을 실행했을 때와 같은 이력이 만들어집니다. 사실 pull 이라는 것은 내부적으로 보면 fetch + merge 이기 때문이죠!

1. git rebase -i main

프로젝트를 통한 경험이 더 필요하다. 2주차 프로젝트 때 사용하고 다시 포스팅하기로 한다.

추가적인 명령어

https://www.daleseo.com/git-add/ 블로그의 내용을 참고하였습니다.

1. git status

git add 명령어는 다음 변경(commit)을 기록할 때까지 변경분을 모아 놓기 위해 사용한다. 따라서 git commit 명령어를 통해 명시적으로 기록을 남기기 전까지는 아무리 git add 명령어를 많이 실행해도 git 저장소의 변경 이력에는 영향을 주지 못한다. git add 명령어를 사용할 때 항상 함께 사용하게 되는 명령어가 git status이다. git status 명령어는 작업 디렉토리와 스테이징 영역의 상태를 확인하기 위해 사용한다.

$ git status
On branch search3
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   src/components/Control/Control.jsx
        modified:   src/components/Input/Input.jsx
        modified:   src/components/List/ListItem.jsx

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   src/components/Search/Search.jsx
        modified:   src/components/Search/Search.stories.jsx

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        src/components/Search/useSearch.js

• Changes to be committed: 이 영역은 스테이징 영역에 넘어가 있는 변경 내용을 보여줍니다.
• Changes not staged for commit: 이 영역은 아직 워킹 디렉토리에 있는 변경 내용을 보여줍니다.
• Untracked files: 이 영역도 아직 워킹 디렉토리에 있는 아직 한 번도 해당 Git 저장소가 관리한 적이 없는 새로운 파일을 보여줍니다.

내 프로젝트 git status

❯ git status                                                                                                                                                                   ─╯
On branch feature/unittest2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   products/tests.py
        modified:   products/views.py

no changes added to commit (use "git add" and/or "git commit -a")

staging 영역

git add 명령어를 사용할 때 반드시 숙지해야 하는 개념이 바로 스테이징 영역이다. 스테이징 영역은 작업 디렉토리와 git 저장소의 변경 이력 사이에 징검다리 역할을 한다. 작업 디렉토리는 아직 커밋할 준비가 안된 변경 내용을 자유롭게 수정할 수 있는 공간인 반면, 스테이징 영역은 커밋할 준비가 된 변경 내용이 git 저장소에 기록되기 전에 대기하는 장소라고 생각하면 된다. git add 명령어를 사용하면 현재 작업 디렉토리에 있는 모든 또는 일부 변경 내용을 스테이징 영역으로 이동시킬 수 있다. (git add 하기 전까지는 작업 디렉토리, git add 후에는 저장소 기록을 위한 스테이징 영역)

git commit 명령어가 변경 이력을 남길 시점에는 작업 디렉토리에 있는 변경 내용은 고려하지 않는다. 스테이징 영역으로 넘어온 작업들만 commit이 가능하다.

이렇게 작업 디렉토리와 스테이징을 구분하면 변경 이력을 남길 때 작업 디렉토리에 있는 변경 내용을 한 번에 몽땅 기록하지 않고, 조금씩 나누어서 기록할 수 있다는 장점이 있습니다. 이를 통해, 각 변경 기록(commit)에 논리적으로 하나의 변경 사항을 담기가 용이한데 이렇게 하면 나중에 버그를 추적하거나 변경 이력을 롤백(roll back)할 때도 이점이 있습니다.

• git add -A : 현재까지의 작업 디렉토리 내용을 모두 스테이징 영역으로 넘기고 싶을 때 사용. git add . 과 다른 점은 후자는 명령어를 실행한 디렉토리 이하에서 발생한 변경 내용만 포함한다는 것.

마지막으로 소개해드릴 옵션은 제가 개인적으로 유용하고 쓰고 있는 -p 인데요. 이 옵션을 사용하면, 각 변경 사항을 터미널에서 직접 눈으로 하나씩 확인하면서 스테이징 영역으로 넘기거나 또는 제외할 수가 있습니다. 많은 변경 내용을 여러 개의 변경 기록으로 나누어서 남기고 싶을 때 유용하게 사용할 수 있습니다.

2. git stash

https://gmlwjd9405.github.io/2018/05/18/git-stash.html 블로그의 내용을 참고하였습니다.

아직 마무리하지 않은 작업을 스테이징 영역에 잠시 저장할 수 있도록 하는 명령어.

git stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일들만 저장한다.
stash란 아래에 해당하는 파일들을 보관해두는 장소 이다.

Modified이면서 Tracked 상태인 파일
Tracked 상태인 파일을 수정한 경우
Tracked: 과거에 이미 commit하여 스냅샷에 넣어진 관리 대상 상태의 파일

Staging Area에 있는 파일(Staged 상태의 파일)
git add 명령을 실행한 경우
Staged 상태로 만들려면 git add 명령을 실행해야 한다.
git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다.

• git stach list : stash 목록 확인
• git stash apply : 했던 작업을 다시 가져오기, apply 뒤에 stash 이름을 붙여준다.
• git stash drop : apply 옵션은 단순히 stash를 적용하는 것으로, 해당 stash는 여전히 스택에 남아있다. 스택에 남아 있는 stash는 위의 명령어를 사용하여 제거할 수 있다. 뒤에 이름을 붙여준다!

우선 이 정도로 기본적인 내용에 대한 정리를 마친다. 부트캠프에서는 억지라로도 사용을 해야 했었으나(그때도 도움을 많이 받으며 했다..ㅜ) 혼자 프로젝트를 하다보니 git을 정말 등한시 했던 것 같다. 앞으로 프로젝트 때 적극적으로 적용하면서 공부할 것이다.