GIT 주로 사용하는 명령어 모음

GIT 3가지 영역을 배경으로 주로 사용하는 명령어들을 설명하려고 한다.

GIT 3가지 영역

GIT 3가지 영역을 항상 사용하기 때문에 반드시 인지

• 스테이징 영역 : git add로 보내는 곳
• HEAD 영역 : 현재 Git 저장소가 가리키는 곳 (원격 저장소)
• 워킹 트리 영역 : 작업 디렉터리 (예로 로컬)
• 중요!) HEAD와 워킹 트리의 변경사항을 매번 비교 -> 모든 변경 사항을 바로 커밋하는 게 아니라 스테이징(=INDEX)에 추가된 내용만이 커밋

주로 사용하는 명령어

• git init : Git 저장소를 초기화

  • 워킹 트리 생성 효과
  • git status -> No commits yet 출력
  • HEAD가 가리키는 커밋이 없는 특수한 상태!

• git reflog : HEAD가 가리키는 커밋 출력

  • HEAD는 최종적으로 커밋한 시점의 “워킹 트리 스냅샷”
  • 단, 어느 커밋이든 HEAD가 되게끔 자유자재로 다룰 수 있음
• git clone : 원격 저장소를 가져옴
  • git clone [REPO_URL] [DIR]로 디렉터리를 지정할 수 있다!

• git add : 스테이징 영역(INDEX)에 파일 추가!

  • 스테이징에 추가된 변경 내역들만 commit 후보가 될 수 있는 것!

• git status : HEAD, 워킹 트리, 스테이징을 비교!

  • git status -s 추천 : ??은 Untracked / M 커밋 대상 / D 커밋 대상 / MM 커밋 대상+워킹 트리 변경
    • 첫 번째는 스테이징 영역, 두 번째는 워킹 트리 영역!
  • Git 저장소의 상태를 확인
  • “working tree clean” - HEAD, 워킹 트리가 동일을 의미 (원격 <-> 로컬 저장소 동일 의미)
  • “Untracked files” - 워킹 트리에 있으나 HEAD, 스테이징엔 없는 경우를 의미
  • “Changes to be committed” - 이미 스테이징된 커밋 후보들을 의미
  • “Changes not staged for commit” - 이미 스테이징된 파일이 변경된 경우를 의미
    • 변경 내역을 새로 스테이징 하려면 git add를 또 해줘야 함!
  • “discard changes” - 변경 내용 삭제 의미
  • “staged changes” - 변경 내용 유지 의미
• git commit : 새로운 커밋 생성

• git stash 사용법: 커밋하지 않고 변경사항 저장하는 방법

  • “Changes to be committed, Changes not staged for commit” 같은 변경사항들을 쉽게 저장
  • 커밋으로 변경사항 저장 후 해당 커밋을 수정해도 되지만 커밋 쓰고 싶지 않을 때 유용
  • git stash pop 저장한 내용 사용

• git revert : 커밋한 내용을 되돌리기(커밋 새로 씀)

  • git revert 커밋 ID –no-edit : 특정 커밋으로 이동, no-edit은 커밋 메시지 수정 생략

  • 브랜치를 입력해도 이동 가능

    • 해당 브랜치의 최신 커밋 ID를 자동으로 기입해주기 때문
  • merge한 커밋의 경우
    • git cat-file -p 커밋 ID : merge하는 부모 커밋 2개 확인
    • git revert 커밋 ID -m 1 or 2
  • 참고 : git revert 자세한 동작 원리

• git reset : 커밋한 내용을 되돌리기(히스토리를 고쳐 씀)

  • git reset –hard 커밋 ID : 강제 PULL에 효과적, 브랜치도 가능

• git rebase : 커밋 수정하기

  • 예시) git rebase -i 수정할 커밋 이전 이름
    • vi 에디터 접근 (:wq-저장&탈출, :q!-탈출)
    • pick을 drop으로 수정(=삭제)

• git merge : 브랜치 병합

  • git merge 브랜치명 : 작성한 브랜치와 현재 브랜치를 병합합니다.
  • git merge –no-commit –no-ff 브랜치명 -X theirs : 다른 브랜치 특정 파일(폴더) 병합 - 강제로
    • git reset HEAD 파일명1 파일명2 : 기존 브랜치의 파일을 보존도 가능
    • -X theirs : 충돌이 발생한 경우, 대상 브랜치의 변경 사항이 현재 브랜치의 변경 사항을 덮어씁니다.
• git checkout -p : 다른 브랜치 특정 파일(폴더) 병합 - 패치 모드

• git clean : Git으로 관리되지 않는 파일 정리

  • git clean -f : Untracked 파일들을 일괄 삭제 - 단, -f 옵션 필수
  • 2가지 관점 : Git 저장소에서 관리되는 파일 / 관리되지 않는 파일(Untracked)
  • 주의 : merge 커밋을 되돌릴 때는 꼭 어떤 커밋으로 되돌릴지 명시해줘야 한다.
    • 참고 : revert, reset 관련 내용

스티커 메모장

실제로 스티커 메모장에 기록해두고 사용 중인 GIT 명령어

스티커 메모장

GIT 리뉴얼
GIT 설치 -> CLI, WINDOW 중 CLI 방식 사용 : git bash
cd, ls 등등 명령어 다양
code . 는 현재 경로에 VSCODE 오픈

<0. 브랜치 전환 & 충돌해결> - switch도 많이사용
git branch -a : 로컬 저장소 브랜치 확인
git branch -r : 원격 저장소 브랜치 확인
git branch -d 브랜치명 - 로컬 브랜치 삭제
git branch 브랜치명 : 브랜치 생성
git checkout 브랜치명 : 브랜치 변경
git checkout -b 브랜치명 : 변경 및 없으면 생성

conflict(충돌) 해결 예시
원격 저장소에 누군가 PUSH
-> 본인이 PUSH 할 때 conflict.. rejected.. hint.. git pull
-> PULL 및 로컬 저장소에서 conflict(충돌) 해결
-> 충돌지점 표시해주므로 직접 수정!!
-> 수정사항 다시 스테이징(add) 후 commit 
-> 만약 vim 에디터 이동시?
- i로 insert mode / esc로 default mode
- wq 저장후 탈출 / q! 저장X 탈출
-> 최종 PUSH 끝.


<1. 로컬 저장소 PUSH>
git checkout 브랜치명 : 원하는 브랜치로 이동
git status -> git add .(URL) -> git commit -m "docs:"
git push -u origin main : -u 생략가능
git push origin main : origin 뒤에 원하는 branch명

-u : upstream(GIT저장소와 매칭) 연결
origin : GIT저장소 별칭(GIT저장소임을 표시)


<2. 원격 저장소 PULL> - CONFLICT 조심
git checkout 브랜치명
git pull origin 브랜치명 : 원하는 브랜치 PULL

(2-1) 원하는 브랜치"만" PULL - clone 사용
git clone --single-branch -b 브랜치명 URL주소

(2-2) 원하는 브랜치"만" PULL - clone 미사용
git init
git remote add origin URL주소
git pull origin 브랜치명

(2-3) 전체 브랜치 PULL
git clone URL주소 : 자동으로 main을 가져옴
git branch -a : remotes/... 브랜치들 자동 생성
git checkout 브랜치명 : 해당 브랜치 생성 및 remotes/... 에 맞는 브랜치명 자동 매칭
git pull origin 브랜치명
=> 이미 clone으로 다 땡겨왔으므로 의미가 없긴 함

(2-4) 강제로 원하는 커밋(브랜치) PULL
git checkout 브랜치명
git reset --hard origin/브랜치명
git reset --hard 커밋ID
=> 브랜치, 커밋 둘다 가능 (브랜치는 최신커밋 사용)


<3. 병합> - conflict(충돌) 해결 중요!
(3-1) 다른브랜치 병합 - merge
git checkout main
git merge kbh
=> conflict 없으면 커밋 바로 생성
=> 자세한 설명 생략(보통 웹에서 PR 하는중)

(3-2) 다른브랜치 특정 파일(폴더) 병합 - 강제로
A브랜치에서 pers..., READ,,, 파일 2개만 남겨두고,
나머지 B브랜치의 모든 변경 사항을 덮어쓰고 싶다면?
git checkout A
git merge --no-commit --no-ff B -X theirs
git reset HEAD personalConfig.js README.md
git clean -fd : 강제실행(f), 삭제허용(d) clean
git commit -> push 하면 원격저장소에 저장

-X theirs : 충돌이 발생한 경우, 대상 브랜치의 변경 사항이 현재 브랜치의 변경 사항을 덮어씁니다.

(3-3) 다른브랜치 특정 파일(폴더) 병합 - 패치모드
main 브랜치 파일을 kbh 브랜치 파일로 가져온다면?
git checkout main
git checkout -p origin/kbh -- 가져올 파일경로
=> 하나하나 변경사항 보고 스테이징 가능한 장점!!
=> y, n 등등 명령어로 conflict 해결후 커밋!


<4. 커밋 수정, 되돌리기> rebase, reset, revert
reset은 히스토리를 고쳐써서 revert를 권장(커밋을 남겨줌)
git reset --hard 커밋ID : 강제 PULL에 효과적
git reset HEAD~1
=> soft는 모든 변경사항이 남고, hard는 없다.
git revert HEAD : HEAD는 돌아갈 커밋 의미
=> 단, merge 커밋의 경우
- git cat-file -p 커밋ID : merge하는 부모 커밋 2개 확인
- git revert 커밋ID -m 1 or 2
git rebase -i 수정할커밋 이전이름
- vi에디터 접근 (:wq-저장&탈출, :q!-탈출)
- pick을 drop으로 수정(=삭제)

error: you need to resolve your current index first
-> git reset -merge
git/rebase-merge 관련 에러..
-> git rebase --quit


<5. 캐시 삭제>
수정한 .gitignore 을 인식 못할 경우 캐시 삭제 필수
git rm -r --cached .
git add .
git commit -m "fixed untracked files"


<??. 추가 사용 명령어> - 중요 개념 포함
GIT 3가지 영역 : 스테이징, HEAD, 워킹트리
중요 : HEAD와 워킹트리의 변경사항을 매번 비교 -> 모든 변경 사항을 바로 커밋하는 게 아니라 스테이징(=INDEX)에 추가된 내용만이 커밋

git init : `Git 저장소`를 초기화
git reflog : HEAD가 가리키는 커밋 출력
git status -s : 스테이징 워킹트리 정보제공
git stash : 커밋없이 변경사항 저장
git revert 커밋ID --no-edit : 커밋메시지 생략
git clean -f : Untracked 파일들을 일괄 삭제 


==================================
==================================


<나머지 정리X>

<1. 새로운 부분(번외) : 커밋 이동>
기존 커밋 트리구조(가정) : HEAD -> main -> C1(커밋)

1-1-1. 커밋 이름 사용
* `git checkout C1` 적용시 : HEAD -> C1
* 이부분은 커밋 이름(라벨C1)로 chekcout시 HEAD가 변경   
  => HEAD는 현재상태를 의미한다는걸 알 수 있음
  * 물론!! 이 커밋의 이름은 git log에서 보시다싶이 fed2da64c0efc5293610bdd892f82a58e8cbc5d8 이런 형태
  * 근데, git은 fed2 정도만 입력해도 알아서 알아들음!

1-1-2. 상대참조
그래도 이건 귀찮은 작업이라 더 편한게 여러가지 있는데 "상대참조", "git tag" 소개
* 상대참조 : 캐럿(^) 연산자, 틸드(~) 연산자
  * 브랜치와 HEAD 둘다 "상대참조" 사용가능
    * 예로 `git checkout main^` 입력시?? main브랜치가 가리키는 커밋의 부모 커밋을 HEAD가 가리킴.  
      근데, `git checkout HEAD^` 도 가능. HEAD가 가리키는 커밋의 부모 커밋을 가리킴.
    * 예로 `git checkout HEAD~4` 입력시?? HEAD가 가리키는 곳에서 4개 위로 올라가는것임.

1-1-3. git tag
* git tag v0 C1 처럼 커밋에 태그이름(v0)를 임의로 지정 가능
  * 이를 통해서 바로 git checkout v0도 가능
  * git describe main 으로 main브랜치(커밋도가능)에 가까운 태그 정보를 묘사(describe)해줌
  * 출력은 `<tag>_<numCommits>_g<hash>` 형태
    * tag: 가장 가까운 부모태그
    * numCommits : 해당 태그가 얼마나 멀리있는지
    * hash : 묘사하고있는 커밋의 해시(이름)


1-2. Git 작업 되돌리기
`git reset, git revert` 명령어 사용
* git reset HEAD~1 : HEAD의 바로 앞의 커밋으로 이동하는데, 히스토리를 고쳐쓰기 때문에 다른 사람과 작업하는 리모트 브랜치에는 사용X
* git revert HEAD : 위의경우 이 방법을 사용해야 함. 이 방법은 아예 변경내역 커밋을 새로 생성해주고, 이를 다른 사람들에게도 push(변경내역 밀기)할 수 있음

실수로인해 정말 간단히 바로 앞 커밋으로 되돌리는 2줄(HEAD기준)
* git reset HEAD^
* git push origin 브랜치명 -f
  * -f는 force로서 강제 push를 도와주며, 이 경우 정말 실수로 GIT저장소에 잘못 올린경우에 사용할 것
  * revert로 해결을 권장하긴 함


1-3. GIT 작업을 여기저기 이동해보기
`git cherry-pick, git rebase -i` 명령어 사용
1-3.1. git cherry-pick C2 C4 -> 다른 브랜치의 커밋인 C2와 C4를 현재 포인터(브랜치)에 복사하는 아주 간편한 방법.  
   => rebase로도 당연히 가능. 물론 이방법은 커밋의 hash(이름)을 알아야겠죠.
1-3.2. git rebase -i HEAD~4 -> 인터렉티브(-i)라고 해서 직접 트리모형의 커밋구조를 UI로보고 우리가 마우스로도 수정할 수 있는 방식이다.
1-3.3. 응용 : 커밋 딱 한개만 가져오기  
   -> git cherry-pick 커밋1개
1-3.4. 응용 : 서로 연관있는 브랜치에서 이전의 기록꺼를 조금 수정해야할때 어떻게? 우선 이전꺼를 최신으로 순서를 바꿔주고(rebase, amend), 다시 원복해준다(rebase)  
   git rebase -i HEAD~2 / git commit --amend / git rebase -i HEAD~2
1-3.5. 응용 : 방금 한것을 git cherry-pick으로 해보겠음. 변경할 커밋은 C2로 하고, C3이 최신이라 보자.  
   git cherry-pick C2 / git commit --amend / git cherry-pick C3


1-4. 브랜치 이동(접목)
브랜치를 강제로 옮기는 일반적인 방법
* git branch -f main HEAD~3 : 강제(-f)로 브랜치를 이동(HEAD~3위치로)

브랜치 병합하는 또다른 방법
`git merge, git rebase` 명령어 사용
* 만약 두 브랜치에 서로다른 독립된 커밋이 있을경우 어떻게 합치는가?? (bugFix, main 두 브랜치로 가정)
  1-4.1 git merge bugFix -> 현재 브랜치가 main이라 가정하고 merge 명령어를 했다면, 해당 bugFix브랜치의 커밋과 현재 main브랜치의 커밋 둘다를 main이 화살표로 가리킨다.
     => main이 bugFix의 커밋까지 내역을 이제 전부 포함
  1-4.2. git checkout bugFix / git merge main -> 현재 가리키는 포인터(main)을 bugFix로 변경하고, merge main을 진행시 bugFix가 main브랜치 쪽으로 이동하고 성공적으로 merge가 된다.
     => bugFix이 main의 커밋까지 내역을 이제 전부 포함

* 실제론 두기능을 따로 개발헀지만, 마치 순서대로 개발한것처럼 bugFix 브랜치작업을 main브랜치 위로 직접 옮기려고 할때는? (현재 bugFix가 포인터)
  1-4.1. git rebase main -> main위로 bugFix작업 내용이 옮겨지면서 커밋내용도 복사본으로 하나 추가된 상태
  1-4.2. git rebase bugFix -> 포인터를 main으로 옮긴후 다시 rebase를 하면 bugFix쪽으로 간단히 이동함


1-5. 특정 브랜치의 특정 폴더만 가져와보기
`git subtree merge --prefix=폴더_경로 다른_브랜치` 명령어를 사용 (현재 main 브랜치라 가정)
* 여기서 `"폴더_경로"`는 메인 브랜치로 가져오고자 하는 특정 폴더의 경로를 나타내며, 
* `"다른_브랜치"`는 병합하고자 하는 다른 브랜치의 이름입니다.

```