[Git] VScode로 Git 사용해보기 - 기본활용

※ 주의

누군가에게 알려줄 마음보다는

내가 이해한대로, 내가 잊지 않기 위해 작성했을 가능성이 큼(?)

 

---

 

이제 VScode로 Git 연동이 끝났으니 Git의 동작원리를 다시한번 되짚어 보자

[그림 1] Git 동작방식

 

 

바로 이전 게시글에서 VScode와 Git 연동을 마쳤다면

https://dev-kjs.tistory.com/5?category=1054247 

[Git] VScode로 Git 사용해보기 - Git 설치 및 VScode 연동

 

현재 우리는

[ workspace - index - local repository : local PC ] ---- [ remote repository : Github ]

의 구조가 완성된 것이다.

 

 

git clone

원격저장소(remote repository)에 저장소를 복제(clone)하여 해당 폴더로 가져온다.

해당 폴더는 로컬저장소(local repository)가 된다. 

git init 보다 먼저 설명하는 이유는 해당 기능을 더 자주 사용하기 때문

보통 원격저장소가 먼저 생성되어

복제해서 로컬저장소로 가져오는 경우가 더 많다.

우리가 VScode에서 리포지토리복제를 해온 것이 바로 이 명령어다.

 

 

git init

버전관리를 하기위한 새로운 Git 저장소, 즉 로컬저장소(local repository) 를 생성하는 명령어

해당 명령 실행 시 해당 폴더는 Git 저장소로 초기화된다. 

원격저장소(remote repository)를 사용하지 않고 해당 폴더만으로도 버전관리는 가능하다. (이때는 SVN과 동일할 듯)

하지만 보통 원격저장소를 연결하여 사용한다.

※ 폴더에 숨김파일로 git 관련 폴더가 생긴 것을 볼 수 있다.

 

 

brunch

작업환경을 분리시켜 하나의 독립적인 공간을 만들어서 작업을 진행하기 위한 개념이다.

원본에서 분리시킨 공간은 해당 원본을 복제한 공간이고

독립적이기 때문에 지지고 볶고 해도 원본에게 영향울 주지않는다.

단 작업이 완료되면 원본과 병합(merge)을 하여 해당 작업내용을 추가할 수 있다.

 

쉽게 생각하면 우리가 문서작업할 때 원본파일은 그대로 두고 복제해와서 

새로운 파일로 작업을 한 후 작업한 파일이 만족스러우면 해당파일이 원본파일이 되고

문제가 있거나 만족스럽지 못하다면 원본파일로 다시 돌아갈 것이다.

 

 

default brunch

Git 저장소를 처음 생성시 자동으로 만들어지는 가장 기본 brunch이다.앞서 설명한 brunch와 동일하지만 결국 원본이 있어야 brunch를 만들 수 있기에 그 원본이 되는 main brunch라고 생각하면 되겠다. ※ 과거에는 'master', 근래에는 'main'으로 이름이 변경되었다.

 

 

git checkout

brunch간에 이동할 때 쓰는 명령어

소스제어에서 분기(brunch)를 언제든 변경할 수 있다. 

※ origin이 붙은 분기는 원격저장소에 존재하는 분기이다.

 

 

git pull

원격 저장소(remote repository)에서 로컬 저장소(local repository)로 변경된 데이터를 확인하고

최신 데이터를 복사하여 로컬 저장소로 가져온다. 이때 자동으로 commit이 만들어진다.

git clone : 원격저장소의 내용이 로컬 저장소의 내용과 일치해진다. 원격과 똑같은 상태로 복제하기때문.
내가 로컬에서 작업한게 있고 원격에는 없다면 지워질 것이다.
최초에만 실행한다고 보면 되겠다.

git pull : 원격저장소의 내용을 복제해오는 것은 같으나 현재 brunch와 병합(merge)까지 해준다.
쉽게 설명하자면 로컬과 원격을 비교하여 원격에 존재하는 최신 데이터들만 로컬로 병합을 해준다는 것이다.

만약 병합과정에서 원격과 로컬의 수정한 데이터 겹친다면 충돌이 발생하게 되는데

이때는 충돌난 부분을 수동으로 수정 완료 후 commit을 해야한다.

 

 

git add

workspace에서 작업한 변경내용을 스테이징영역(staging area 또는 index)에 추가하는 명령어.

로컬저장소(local repository)에 commit할 파일들을 모아놓기 위해서 사용한다. 

Staging Area (Index)
SVN이나 다른 버전관리 시스템에서와의 큰 차이점이기도 하다.
해당 공간은 로컬저장소와의 징검다리 역할을 하게되는데
커밋할 준비가 된 변경내용들을 Git 저장소에 기록되기전에 대기하는 장소라고 생각할 수 있다.
이후 설명할 commit은 해당 영역에 있는 변경 내용만 로컬저장소로 반영한다.

이렇게 하게되면 장점이 무엇일까?

1. 일부분만 묶어서 커밋하기가 쉬워진다.
workspace에선 자유롭게 고치고 싶고 커밋할 때는 골라서 커밋하고 싶다.
이럴때 staging area가 없었다면, 커밋을 할 때 커밋할 파일만 선택해야 할 것이다.
작업량이 많아지면 선택하는 시간도 오래 걸리고 다시 일일히 확인해야해서 굉장히 어려울 것이다.
하지만 staging area로 인해 손쉽게 골라서 논리적으로 변경사항을 기록(커밋)을 할 수 있다.

2. 충돌을 해결할 때
충돌이 발생했을 때 발생한 파일들 중 필요한 만큼만 충돌을 해소하고
해결된 작업 데이터들을 staging area에 올린 후 커밋을 하면 된다.

 

 

git commit

변경된 버전을 메시지와 함께 로컬저장소(local repository)에 기록하는 것. 

commit을 한다고 해서 원격저장소에는 저장되지 않는다.

이렇게 메시지를 입력하고 커밋을 해도 되고

 

그냥 커밋을 누르면 COMMIT_EIDTMSG 창이 뜨는데 

해당 창에 입력 후 x를 눌러 닫으면 적용된다.

 

 

git log

그냥 git log를 할 경우 로컬저장소(local repository)의 commit history를 보여준다.

기본적으로 작성자, 일시, 커밋 메시지가 보인다.

--all : 모든 brunch 커밋(원격저장소까지)을 함께 보여준다.
--graph : brunch 병합(merge) 히스토리 정보까지 아스키코드로 표현한 그래프로 보여준다.
--oneline : 한줄로 커밋 해시코드와 커밋 메시지를 보여준다.

※ HEAD의 의미
현재 체크아웃된 브랜치의 가장 최신커밋을 가리킵니다. 

: 로컬 저장소(local repository)의 main brunch 가장 마지막 커밋

:  원격 저장소(remote repository)의  main brunch 가장 마지막 커밋

로컬저장소에서만 커밋을 하고 다시 로그를 찍어보면

로컬저장소의 가장 최근 커밋에 HEAD가 가리키고 있으며

아직 원격저장소에 push하기 전이라 원격저장소의 HEAD는 이전 커밋을 가르키고 있다.

 

※ 추가적인 활용

$ git log --graph --all --pretty=format:'%C(yellow)[%ad]%C(reset) %C(green)[%h]%C(reset) | %C(white)%s %C(bold red)%C(reset) %C(blue)%d%C(reset)' --date=short
# 이렇게 format을 지정하면 사용자가 좀 더 편하게 log 결과를 볼 수 있다
# 다만 이렇게 설정하면 너무 길기 때문에 아래처럼 alias를 사용해서 명령어를 줄인다

$ git config --global alias.hist "log --graph --all --pretty=format:'%C(yellow)[%ad]%C(reset) %C(green)[%h]%C(reset) | %C(white)%s %C(bold red)%C(reset) %C(blue)%d%C(reset)' --date=short"
# 이렇게 hist 라는 이름으로 지정해주면 (꼭 hist라는 이름으로 지정하지 않아도 된다)

 

 

git push

로컬 저장소(local repository)의 변경된 내용을 원격 저장소(remote repository)로 적용시킨다. 

몇 번을 커밋을 해도 그것은 로컬저장소에만 반영되며

내가 변경한 파일들을 원격저장소에도 반영하고자 할때 쓴다.

※ 동기화는 pull과 push를 동시에 하여 로컬과 원격저장소를 동일하게 만든다.

 

 

---

내가 까먹을까봐 메모해둔 명령어

git remote prune origin

Git 리모트에 삭제된 브랜치 반영하기

https://velog.io/@devand/Git-%EC%9B%90%EA%B2%A9-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%82%AD%EC%A0%9C%ED%96%88%EB%8A%94%EB%8D%B0-VSCode-%EC%97%90-%EA%B3%84%EC%86%8D-%EB%82%98%EC%98%A4%EB%8A%94-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0

 

 

참조

https://www.daleseo.com/git-add/

https://blog.npcode.com/2012/10/23/git%EC%9D%98-staging-area%EB%8A%94-%EC%96%B4%EB%96%A4-%EC%A0%90%EC%9D%B4-%EC%9C%A0%EC%9A%A9%ED%95%9C%EA%B0%80/

https://github.com/yeoseon/tip-archive/issues/85

https://dkmqflx.github.io/development/2021/01/16/git-log/