학교 친구의 git 강의를 듣고 그것을 정리한 글입니다.
이 글에서는 git 파일의 상태를 다루고 있습니다.
흔히 나의 컴퓨터를 로컬이라 명명합니다.
로컬은 크게 두 가지의 상태를 가지는데, 그것들이 unstaged
와 staged
입니다.
unstaged : 막 새로 생긴 변경사항이 들어갑니다.
staged : 추가된 변경사항이 들어갑니다.
unstaged
에는 아직 저장되지 않은 변경사항이 들어가는 공간입니다.
이 때, add
를 하게 되면 unstaged
에 있던 파일이 staged
로 옮겨집니다.
staged
에는 저장된 변경사항이 들어가는 공간입니다.
이 때, commit
을 하게 되면 staged
에 있던 파일을 푸시를 통해 원격, 즉 깃허브에 올릴 수 있게 됩니다.
git init
내 컴퓨터(로컬)에서 github(원격)로 변경사항을 보내기 위해서는 .git
폴더라는 것이 있어야 합니다.
그렇다면 나의 프로젝트가 담겨있는 폴더에 .git
폴더가 있어야 한다는 뜻인데 이 .git
폴더를 만들어주는 명령어가 바로 git init입니다.
git init
을 통해 비어있는 mygit
폴더에 .git
폴더가 생성이 되었습니다..git
이라는 폴더가 생기면 mygit
은 로컬에서 깃허브로 add
, push
등이 가능한 폴더가 됩니다.만약 자신의 컴퓨터가 윈도우 11인데 git init을 했는데도 .git폴더가 안 보인다면,
보기 -> 표시 -> 숨긴 항목 에서 해제를 해주시면 .git 폴더가 보일 것입니다.
git status
현재 로컬(unstaged)의 변경사항을 확인할 수 있는 명령어입니다.
굳이 쓰지 않아도 되지만 현재 내가 무엇을 빼먹었으며 어디에서 에러가 났는지를 추론할 수 있어 많이 사용합니다.
현재
test.txt
는 unstaged
에 있습니다.
만약 이 파일을 깃허브로 올리고 싶다면 unstaged -> staged로 옮겨야 하는데, 이 때 사용하는 명령어가 바로 git add입니다.
git add 파일명
git add . // 모든 변경사항을 추가한다.
이제 막 변경되었거나 추가된 파일들은 로컬의 unstaged
공간으로 들어가게 됩니다.
하지만 staged
에 있는 파일들만 푸시가 되어 깃허브에 올릴 수 있기 때문에 무조건 unstaged
에서 staged
로 이동을 시켜주어야 합니다.
이 때, 사용되는 명령어가 바로 add입니다.
git add 파일명
으로 특정 파일의 변경사항만 저장할 수도 있고,git add .
으로 모든 파일의 변경사항을 다 저장할 수도 있습니다.초록색 글씨가 보이죠?
이제 test.txt파일이 staged로 옮겨졌다는 걸 확인할 수 있습니다!
unstaged
staged
test2.txt
는 이미 add
가 된 파일입니다. 다시 말해 staged
공간에 있는 파일이죠.
그런데 수정을 하고 나니 다시 unstaged
공간으로 이동하였고, 이는 다시 add를 해주어야 한다는 뜻입니다.
git diff
이 둘의 차이점을 알 수 있는 명령어가 git diff
입니다.
unstaged
에 있는 수정된 파일은 다시 git add .
해주면 staged
로 올라갑니다
파일을 수정했을 때에도 변경사항이 추가된 것이기 때문에 git add
를 꼭 해주어야 함을 기억하세요!
git commit
git commit -m "커밋메시지 입력하기"
git
commit 이란 깃허브에 올라갈 메시지를 의미합니다.
커밋메시지를 통해 우리는 이 사람이 어떤 작업을 했는지를 쉽게 파악할 수 있습니다.
커밋을 할 때는 크게 두 가지 유형이 있습니다.
git commit
git commit -m ""
git commit
git commit
git commit
을 작성하면 다음과 같은 창이 보입니다.
Esc + i
를 누른 뒤에 아래에 Insert가 뜰 때, 비로소 작성을 할 수 있습니다.
커밋메시지를 다 작성하였다면 Esc
를 누른 뒤, 맨 하단에 :wq
를 입력한 뒤 enter
를 치면 커밋이 완료됩니다.
git commit -m ""
git commit -m "커밋 메시지 작성하기"
제일 많이 사용하는 커밋 방법입니다.
이 방법을 쓸 때의 주의사항은 엔터가 먹히지 않는다는 것입니다.
만약 해당 방법으로 줄바꿈을 하고 싶다면 git commit -m "" -m ""
와 같이 -m ""
를 반복하면 줄이 바꿔집니다.
하지만 이렇게 줄이 바뀔 때마다 하나하나 작성하는 것은 번거롭겠죠?
이 커밋 방법은 한 줄을 작성할 때 적합합니다.
이렇게 커밋하면 test.txt
는staged
에서 삭제가 되며 드디어 github
에 올려질 준비가 끝나게 됩니다!
git log
해당 명령어로는 지금까지의 모든 커밋메시지를 볼 수 있습니다.
커밋한
[feat] test commit
이 보이시죠?
git commit --amend
해당 화면에서 바로 수정이 안 될 경우에는 Esc + i 를 누르면 아래에 INSERT가 뜨면서 수정이 가능해집니다.
커밋 메시지 수정을 완료했다면
수정이 완료됐습니다!
근데 이 상태에서 push를 하면 에러나요
이렇게 커밋메시지를 수정했으면 반드시 강제 푸시를 해줘야 합니다.
강제 푸시 명령어도 많은데요,
git push origin +main (가장 최근에 바뀐 명령어)
git push origin main --force
본인이 원하는 명령어를 사용해서 강제 푸시를 하시면 됩니다.
저는 최근에 바뀐 명령어를 사용했어요!
git push origin +main
근데 나는 한 3일 전에 한 커밋을 3개나 바꾸고 싶다!
그럴 때는 아래와 같은 명령어를 사용합니다.
git rebase -i HEAD~몇개?
위와 동일한 방식으로 작성 완료한 뒤
git log
를 통해 커밋 기록을 보면
커밋 메시지가 수정된 것을 확인할 수 있습니다.
여기까지가 로컬의 끝입니다.
다시 정리!
git push 주소변수명 브랜치명
로컬에서 깃허브로 파일을 올리는 작업입니다.
보통 내 컴퓨터의 주소는 origin
으로, 기본 브랜치명이 main
이므로
git push origin main
로 많이 사용합니다.
이렇게 하면 깃허브에 커밋메시지와 함께 올라가게 됩니다.
git pull origin main
github
에서 변경한 변경사항이 로컬에 적용이 되지 않았을 때 로컬의 내용을 원격과 맞춰주는 명령어입니다.
무조건 내 컴퓨터(로컬)와 깃허브(원격)의 상황은 동일해야 하는데 깃허브에서 변경한 사항을 내 컴퓨터가 모르는 경우에 해당 명령어를 사용합니다.
pull
을 잘 받지 않으면 로컬과 원격 사이에 충돌(conflict)가 일어나는 골치아픈 상황이 연출되므로 주의하세요!