
학교 친구의 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 commitgit commit -m ""git commitgit 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)가 일어나는 골치아픈 상황이 연출되므로 주의하세요!