치춘짱베리굿나이스
Github, Git 기본 <status, add, commit, push> 본문
Github, Git 기본 <status, add, commit, push>
이 포스팅에서는 git status
, git add
, git commit
, git push
에 대해 알아본다
3. Git 상황 체크하기, git status
레포지토리 안의 파일을 열어서 수정해보자
$> git status
위 명령어를 입력하면 마지막 커밋 시점에서 변화가 생긴 파일이 있는지 볼 수 있다
modified
상태인 것으로 보아 값의 변경이 이루어졌다고 볼 수 있다
상태 종류
untracked
: 깃에서 감지하지 않는 파일이다- 마지막 커밋 이후에 생성한 파일일 경우, 깃이 아직 해당 파일을 감시 (tracking) 하지 않기 때문에 어떠한 변경점도 인식하지 못한다
- 따라서 untracked인 파일은 암만 값을 수정해도 깃이 변경점을 알아차리지 못한다
unmodified
: 아무런 변경점도 없는 파일이다git status
명령어 결과에서 이름이 출력되지 않는 파일들이다- 아무런 변경점도 없기 때문에 신경쓰지 않아도 된다
modified
: 변경점이 있는 파일이다- 마지막 커밋 이후로 수정사항이 있으므로, stage하여 스냅샷을 최신으로 유지하자
staged
: 스테이지된 파일이다git add
명령어를 통해 파일의 변경점을 스테이징할 수 있다- 변경점뿐만 아니라 새 파일도
git add
로 추가하면 다음 커밋 시점부터는 깃이 제대로 감시하게 된다
deleted
: 삭제된 파일이다- 마지막 커밋 이후로 삭제된 파일들이다
- 삭제된 상황 (위의 이미지에서의 상황) 에서 stage 후 커밋하면 해당 파일은 완전히 삭제되고, 깃이 더이상 추적하지 않는다
- 커밋 히스토리가 남아있다면 다시 복원할 수 있다
4. 코드 stage하기, git add
$> git status
README.md를 수정하고 git status
를 입력해 보았다
아직 README.md의 변경점이 stage되지 않았기 때문에 Changes not staged for commit이라면서 파일명이 빨갛게 나온다
$> git add README.md
$> git status
README.md를 깃에 add하고, git status
를 다시 입력하면 이번에는 Changes to be committed라면서 파일명이 초록색으로 출력된다
말 그대로 커밋이 될 준비가 되었다는 의미이며, stage 작업을 통해 깃은 이 파일의 변경점을 어딘가에 저장해 스냅샷으로 만들 준비가 되었다
5. 코드 스냅샷 만들기, git commit
$> git commit
git status를 했을 때 staged된 변경점들이 있다면, 이것들을 묶어서 커밋해보자
git commit
명령어를 사용하면 된다
명령어를 입력하면 갑자기 왠 텍스트 에디터가 나온다
당황하지 말자 맨 위에 커밋 메시지를 적으면 된다
메시지를 적고 해당 텍스트를 저장 후 종료하면 자동으로 커밋이 된다
$> git commit -m "[커밋메시지]"
-m
플래그를 이용하여 한번에 메시지까지 입력하는 방법도 있다
보통은 이게 간편해서 좋지만, 만약 커밋 메시지를 좀 길게 남길 필요가 있을 경우 전자의 방법을 사용하면 되겠다
가끔 커밋 메시지에 공동작업자를 표기하거나, 변경점을 요약하려면 개행이 필요하기 때문에 종종 사용된다
6. 커밋을 원격 저장소에 기록하기, git push
$> git log
로그 명령어를 통해 커밋을 출력해보았다
꽤 많은 커밋이 쌓였으니 이것을 원격 저장소에 올려보자
$> git remote -v
$> git remote set-url [리모트 이름] [리모트 저장소 주소] # 주소 변경 또는 설정
위의 명령어로 현재 깃에 설정된 리모트 저장소의 이름과 주소를 볼 수 있다
만약 레포지토리 주소가 변경되었다면 set-url
옵션을 통해 주소를 변경해줄 수 있다
$> git push origin main
$> git push # git push -u origin main 으로 기본값 설정을 했을 경우
push
명령어를 이용하여 원격 저장소에 커밋들을 올려보자
첫 번째 인자는 위에서 설정한 리모트 저장소의 이름이고, 두 번째 인자는 브랜치 이름이다
따라서 git push origin main
은 origin
이름을 가진 저장소의 main
브랜치에 커밋을 올리겠다는 뜻이다
기본적으로 깃 레포지토리를 생성하면 origin은 해당 원격 레포지토리의 주소로 설정되어 있으므로, 굳이 지워주지 않는 한 원활히 동작한다
또한 push 위치를 -u
플래그를 통해 기본설정 해주었거나, 깃허브에서 저장소를 clone받았다면 굳이 다른 설정을 할 필요 없이 git push
만으로도 원격 레포지토리에 잘 올라가도록 설정되어 있다
$> git config --global push.default current
push
위치는 git config
명령으로도 설정할 수 있으며, current는 현재 작업중인 브랜치로 올라간다는 것을 의미한다
이렇게 한번 설정해 두면 그 뒤부턴 git push
만 써도 잘 올라간다
참고 자료
'이론적인 부분들 > Git Github' 카테고리의 다른 글
Github PR 리뷰하기 (0) | 2022.07.23 |
---|---|
Github, Git 기본 <Pull Request, pull, 충돌 해결> (0) | 2022.07.23 |
Github, Git 기본 <레포지토리 생성 및 클론> (0) | 2022.07.23 |
Gist 사용하기 + 삽질의 기록 (0) | 2022.07.19 |
Github Wiki 작성하기 (0) | 2022.05.05 |