자주 쓰는 git 커맨드 모음 101 🍳

git status

• 깃이 인식하고 있는 플젝 디렉토리의 현재 상태를 보여줌
• Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음)
• 하기의 경우는 커밋할게 없는, 이전 커밋과 변경된 부분이 없음
  
  
  
• 하기 예제를 보면, calculator.py는 add가 되어 staged가 되었으나, License.txt 파일은 not staged (= add가 되지 않은 상태, 커밋에 반영되지 않음) 임을 나타내고 있다.
  

git add

• Staging area에 파일을 올리는 행위
• git add [파일 이름] : 수정사항이 있는 특정 파일을 staging area에 올리기
  • 파일을 개별적으로 하나씩 올려도 되고, 폴더명(/ 포함)으로 지정하면 폴더내 모든 파일들이 add/staged 됨
    git add 폴더명/
  • 변경한 파일 모두를 한번에 add 하는 방법은 git add . 사용
    . 의 뜻은 현재 프로젝트 디렉토리 내에서 변경사항이 생긴 모든 파일들을 staging area에 추가 (폴더명이랑 같은 원리)

git init

• 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
  

git commit -m "코멘트"

• 코멘트는 항상 따옴표 표시
• 커밋에는 어떠한 커밋 내용이 있는지 적는 것이 default

git push

• 로컬 레포지토리 내용 --> 리모트/원격 레포지토리(Github)에 반영
• local repository에서 발생하는 새로운 커밋들은 remote repository에도 반영해줘야 하는데, 이때 사용하는 git command가 바로 git push !
• Main --> Main 로컬 레포지토리에서 원격 레포지토리로 이동하였다는 의미
• 

c.f working tree clean

working tree = working directory
clean = 이전 커밋 이후로 변경사항 없다는 의미 , literally clean !

git pull

• 리모트 레포지토리에서 바뀐 내용을 로컬 레포지토리에도 반영하기
  
• Remote Repository --> Local Repository 반영하는 과정
• 이슈없이 pull이 진행이 되면, 하기와 같이 이동과정의 로그가 발생
  

요약하자면 하기와 같이 도식화를 할 수 있다 ! 🎨

리포트 레포지토리를 왜 사용하는 이유는 (동일한 로컬 레포지토리가 있음에도 불구하고), 크게 안정성과 다른 개발자들과 협업이 가능하다는 점이다.

git clone : GitHub project의 repository 복제 🎁

관심있는 프로젝트가 있다면, 검색하여 나오는 플젝의 code 들어가서 clone 사이트 가져오기

• 현재 git에 자신이 레포지토리에 있는지 확인하고, 있는 상태에서 클론을 하게 되면 프로젝트끼리 엉키기에 반드시 레포지토리를 나와서 진행 >> git clone 복사한 주소

git log : 커밋 히스토리를 보기 위해 사용

지금까지 진행하였던 커밋 이력(commit history)을 보여줌

• 가장 최근의 커밋이 위에 있고, 오래된 커밋이 아래에 위치함
• Git Commit : Git은 각 commit을 구별하기 위해 각각의 ID를 부여 (= commit hash)

보통의 git log에서는 git commit / author / Data / Commit message 의 내용을 보여줌

조금 더 깔끔하게 보기 위해서는 git log --prettry=oneline 사용하면 된다 :)
Commit ID와 Commit message 가 하기처럼 한줄로 예쁘게 보여진다 !

-> 총 5번의 커밋 아이디가 있는 것으로 미루어 보어, 5번의 commit을 진행하였음을 알 수 있다 :)

긴 커맨드 aliasing 으로 만들기 - git config 사용

깔끔하게 정리된 commit history를 볼 때, git log --pretty=oneline 작성하였는데 옵션이 많다보니 매번 작성하기가 귀찮을 때가 있다. 이럴 때 alias 를 이용하면 해결 !

• git config alias.[새로운 별명] '[길이가 긴 커맨드]'

git config alias.history 'log --pretty=oneline'

• 위의 예시에는, git history로 사용 가능
• 길이가 긴 커맨드는 반드시 '' 로 둘러야 함 !

--> 주의해야 할 점은 git에 원래 있는 커멘드가 아니라 만들어진 alias 라는 사실 인지하기 !

git show Commit_ID

• 어떤 부분이 달라졌는지를 보여줌
• git show [커밋 아이디]를 실행하면 해당 커밋 아이디를 가진 커밋에서 어떤 변화(어떤 파일이 생기고, 기존 파일에서 어떤 부분이 수정되고 등)가 있었는지를 한눈에 파악 가능
• 커밋 아이디는 전체가 아닌, 앞의 네자리를 치면 나옴
  --> 아이디 전체를 치는 것이 디폴트이나, 보통 엄청나게 많은 커밋을 하지 않는 이상 앞 네자리 XXXX 만 적어도 알 수 있음
• (-)는 해당 커밋의 이전 모습
• (+)는 해당 커밋에서의 모습
  --> 하기 스크린샷을 보면, 빈칸 + 한줄이 추가되었음을 알 수 있다. 즉, 어디에서 달라졌는지 확인 가능
  

git show 하나의 commit_ID 여도 동작원리는 diff
임의적으로 해당 commit_ID의 현 모습을 a & 이전 모습을 b라고 하면, 밑단에서는 diff ver_b ver_a 로 작동된다 ! 그리고 b는 항상 현 커밋의 바로 이전의 커밋 을 가리킨다.

v1 / v2 / v3 (current)

• git show v3 = git diff v2 v3
• git show v2 = git diff v2 v1
• git show v1 = git diff v1 v0 --> 이전 파일은 없고 새로 생긴 경우이므로 new file mode

또 다른 경우는 해당 commit ID에 수정 사항이 2개 반영되어 있는 경우라면, 각 다른 diff가 두개 돌아가는 결과와 같이 나온다.

예를 들어, c8cc 라는 commit ID에 calculator.py 수정과 Text.txt 새롭게 추가된 부분이 반영되어 있다면, 하기의 과정을 거치된 된다 ! 🎨

• calculator.py 와 관련된 diff
• Text.txt와 관련된 diff

git diff 이전커밋ID 이후커밋ID

• 두 커밋의 차이점을 비교하고 싶을 때 사용하는 커맨드
• (ex) 하기의 경우를 보면, README.md 의 변동이력이 확인되는데 이 둘의 차이점을 보기 위해서는 git diff 03af c519 사용하여 확인 (이전 커밋을 먼저 쓰는 것을 잊지 말자 🩰 )

• 이전 commitID와 이후 commitID의 동일 범주 유무에 따라, 동일 파일 비교 or 각각의 파일 버전 비교로 나뉘어진다는 점을 인식하기 👓

--> 사실 같은 범주가 아니라면, 서로 비교할 이유가 크게 없긴하다 ㅎㅎ

<비교하기>

• 동일 파일의 수정 O
  

• 동일 파일의 수정 X
  

-m 옵션 없이도 커밋 메세지 남기는 방법

• git commit 이후 텍스트 에디터에서 커밋 메세지 남기는 방법
• 입력을 할때, i 입력 후 데이터 입력 > 완료 후 저장을 위해서 ESC 누르고 :wq

git commit --amend

• 최신 커밋을 다시 수정하여 다시 새로운 커밋으로 만들기

git reset 파일_이름

• 해당 파일을 staging area에서 파일 제거
• 그러나 변경된 새모습은 당연히 working directory에 남아있음 (unstaged만 되었을 뿐!)
• add를 잘못하여 staging area에서 내리고 싶을 때
  • unstaged & working directory에 남아있는 경우
  • unstaged changes after reset = staging area에서 제거된 변경 사항이 있다는 뜻
  • 

• (ex) 하기 스크린샷을 보면, staged에서 modified 였던 calculator.py 가 reset을 통해 unstaged 상태로 변경된 것을 확인할 수 있다 !
  
  

HEAD 의 의미

• 보통 HEAD이라고 하면, 어떤 특정 커밋을 지칭함
• HEAD 가 가리키는 커밋 & reset option에 따라 working directory가 구성
  

git reset

• HEAD가 과거의 커밋으로 가리키게 할 때 사용
  • Working Directory의 경우, HEAD & reset option에 따라 구성
• 하기 케이스의 경우, 현재 HEAD = Working Directory = 커밋4로 구성되어 있으나 과거의 커밋으로 이동 및 WD까지 변경하여 진행하고 싶을 때 git reset --hard 을 사용
  - (ex) git reset --hard 커밋2_ID : HEAD = Working Directory = 커밋2 로 변경

하기 MathTool 로 예시를 들어본다면, 현재 git에서 HEAD는 가장 맨 마지막에 한 commit이다. --> Commit ID:6099

origin/main 이라는 문구는 local repository를 지칭
main은 remote repository
--> 보통 로컬과 리모트 레포지토리의 버전의 일치 여부를 확인할 떄 용이함

이전 커밋으로 잘 돌아갔는지 확인해보자!🎇🎈

최신 커밋이 곱셈 함수를 추가한 것이므로, 이전의 값은 하기와 같이 Multiple 함수가 없는 상태로 돌아가면 제대로 reset 완료 !

만약 다시 원래 상태로 가고 싶다면, 가고 싶은 commit ID을 확인할 수 있는 git reflog 을 통해 파악하고, git reset --hard 가고싶은_commitID 를 치면 HEAD를 바꿀 수 있다. 수정 후 log를 살펴보면 다시 origin/main으로 HEAD로 간 것으로 확인할 수 있다 ! 🎉

HEAD 이동 후 cat calculator.py를 통해 내용을 확인해보면, multiply 함수를 확인할 수 있다 !

git reset에 있는 옵션의 의미는 무엇일까?

HEAD가 과거의 커밋을 가리키게 되는 결과는 git reset에서 어느 옵션을 쓰든 항상 같지만, working directory의 내부도 과거 커밋의 모습처럼 바뀌는 부분은 어느 옵션을 사용하느냐에 따라 다르다 !

HEAD와 같이, Working Directory도 과거 커밋의 모습과 같이 같이 바뀌게 하는 부분은 --hard 옵션을 사용해야 한다. 만약 --soft,--mixed 옵션을 쓰면 Working Directory의 모습은 각각 다르다.

정리하자면 hard / mixed / soft 옵션은 Git의 세가지 영역 (Working Directory / Staging area / repository) 중 몇개의 영역을 리셋하는지에 따라 나눌 수 있다.

• soft : 1 --> staging area와 working directory에 변화가 없이 그대로 !
• mixed: 1 & 2
• hard : 1 & 2 & 3

사실 Git을 처음 공부하다보니 reset 옵션을 쓰는 이유를 정확히 온몸으로 깨닫지는 못하겠다. 이론상으로는 차이점을 알겠지만, 언제 어떤 상황에서 옵션을 다르게 사용하는지 실질적인 이유는 아직 딱 알지 못하겠다. 조금 더 깊게 유의하면서 공부해야겠다 ! 🎄

일단 지금까지 내가 이해한 부분을 표로 도식화하였다. 실제로 더 공부하면서 보완해나가야겠다.

• 핵심 여부는 add 이전 / 이후 상태로 갈지, WD의 경우는 변하지 않는 것이 default
• --hard의 경우, 위의 로직 beyond 이기에 모두 바뀌는 부분으로 이해