Git 시작하기(feat. VS Code)

준비물

• Git-2.33.1-64-bit
• VSCodeUserSetup-x64-1.62.3
• python 3.8 버전(버전은 크게 상관 X)

VS Code extensions

• GitHub Pull Requests and Issues
• Git History

시작하기에 앞서

시작하기에 앞서 깃허브 회원가입을 권장한다.

로컬에서 작업한 깃 레포지토리를 웹이 저장할 수 있고 쉽게 공유도 가능하다.

아래 목차 중 5번은 깃 허브 아이디가 있어야지 진행할 수 있다.

1. git 시작하기
2. git 작업 현황 확인
3. 스테이징 staging
4. 커밋 commit
5. Push로 원격 저장소에 올리기
6. git history 시각화

 

1. git 시작하기

git 개발환경을 구축하는 방법은 두 가지가 있다.

• 작업 폴더에서 git init 명령어 실행
• 깃 허브에서 직접 레포지토리를 clone

$ git init
$ git clone https://github.com/계정url/레포지토리url

git init은 .git 이라는 폴더를 작업폴더에 생성해서 해당 폴더를 git repository로 만드는 기능이다.

clone 같은 경우는 깃허브 url에서 git repository 전체를 받아온다.

 

이번 포스트에서는 git init으로 작업을 시작해 보자.

모든 작업은 vscode에서 작업을 진행했다.

 

vscode로 작업폴더를 연 후, ctrl+` 를 누르면 터미널이 열린다.( ` 는 ~ 버튼이다.)

터미널을 연 후 아래와 같이 Git Bash를 열면 된다.

깃 배쉬를 열었으면 깃 배쉬에서 아래 작업을 따라해 보자.

 

1) 작업 폴더 생성

2) 작업 폴더로 이동

3) git init 시작

4) 작업 파일 생성

$ mkdir test
$ cd test
$ git init
$ touch test.py
$ vim test.py

5) 작업 파일 수정 (vim으로 하지 않고 vscode로 .py 파일을 만들어도 무관)

※ 짧은 vim 명령어 설명 ※
1. i (텍스트 삽입 모드 명령어 )
2. 코드 작성 (아래 파이썬 코드)

def greeting():
    print("hello world!")

def main():
    greeting()

if __name__=="__main__":
    main()

3. esc (삽입 모드 종료)
4. :wq (저장 후 종료)

6) 파이썬 파일 실행 확인

$ python test.py

위와 같이 작업하려는 폴더에서 git init 명령어를 실행하면 현재 작업 위치 옆에 (main)이라는 글씨가 생성된다.

생성된 git의 main branch에서 작업 중이라는 의미다.

그리고 파일을 작성하면 vscode 탐색기에 생성된 파일 test.py에 초록색으로 U라는 표시가 뜬다.

U는 Untracked file, 추적 안 하는 파일이라는 의미이다.

현재는 없지만 수정된 파일은 M: Modified file로 뜨게 된다.

추적 안 하는 파일은 기존 작업 상황과 비교했을 때 새로 생성된 파일이라는 의미다.

 

 

2. git 작업 현황 확인

$ git status

git status 라는 명령어를 치면 현재 Untracked files: 에 방금 생성한 test.py가 보인다.

git add <file> 이라는 명령어를 통해 커밋할 목록에 포함하라는 말을 확인할 수 있다.

On branch main
   -> 현재 작업중인 브랜치 이름은 main 이다.
No commits yet
   -> 아직 어떠한 commit도 없다.
Untracked files:
   -> 스테이징 되지 않은 파일들의 목록(commit 하지 않는 파일들)
nothing added to commit but untracked files present (use "git add" to track)
   -> 현재 스테이지에 파일이 없다 -> commit할 파일이 없다.

vscode gui로도 확인해 보자.

이런식으로 GUI로도 확인할 수 있다.

1. 소스 제어 레포지토리 - 현재 제어 가능한 git 레포지토리를 의미한다.
2. 소스 제어 - 위 목록에서 선택된 git 레포지토리의 세부사항을 확인할 수 있다.
   2-1. 메시지창 - 커밋할 때 작성하는 메시지를 작성하는 창
   2-2. 변경 사항 - stage에 들어가지 않은 변경사항을 알려준다.

즉, GUI를 보고 현재 작업중인 레포지토리는 test 이며, 1개의 변경사항이 있고, 변경사항은 새 파일이 생성된 것임을 알 수 있다.

 

 

3. 스테이징 staging

git에 파일을 commit하기 위해서는 stage에 파일을 올려야한다. 이를 staging이라고 한다.

GUI와 CLI 모두 가능하다.

 

먼저 CLI 부터 알아보자.

$ git add test.py
$ git add .

위에 git status를 확인할 때 이미 언급했지만, git add 명령어를 통해 스테이징할 파일을 선택할 수 있다.

git add <파일명> 을 하면 해당 파일만 스테이징 하는 것이고

git add . 을 하면 Untracked와 Modified 상태인 모든 파일을 스테이징 한다.

 

gui로 빠르게 몇개의 파일을 생성하고 스테이징을 해보자.

기존에 있던 test.py 외에 test.txt, my_adder.py, simple_calculator.py 파일을 생성했다.

git add test.py를 하고 난 후 git status를 확인한 결과다.

위의 git status에 없었던 추가된 의미를 파악해 보자.

Changes to be committed:
   -> 커밋 될 변경점들.
(use "git rm --cached <file>..." to unstage)
   -> unstage를 하려면 git rm --cached <파일명> 명령어를 쳐라.
new file:   test.py
   -> commit 가능한 추가된 파일이 어떤 것인지. new file은 새로 생성된 파일이라는 뜻

왼쪽 GUI에서도 변화를 확인할 수 있다. 일단 소스 제어 레포지토리 test 부분의 맨 오른쪽 숫자가 1 -> 4로 변했다.

이는 변경된 파일이 4개라는 의미이다.

스테이징된 변경 사항 - 말 그대로 스테이징된 파일 목록을 보여준다. A가 붙은 파일은 Added 라는 의미.
변경 사항 - U가 붙은 파일들은 새로 추가된, Untracked 파일 목록 변경된 파일은 M이 붙는다.

 

GUI에서도 스테이징을 하는 기능이 있다.

위와 같이 스테이징 할 파일에 마우스를 올린 후 + 버튼을 클릭한다.

 

그럼 아래와 같이 스테이징이 되는 것을 확인할 수 있다.

"변경 사항" 에 마우스를 올리면 git add . 과 같은 효과인 전체 스테이징을 할 수 있다.

 

3-1 언스테이징 unstaging

혹시 파일을 잘못 스태이징 했다면 언스태이징을 할 수 있다.

마찬가지로 GUI, CLI 다 가능하다.

$ git rm --cached test.py

git rm --cached <파일명> 명령어를 치면 위와 같이 다시 변경 사항으로 바뀐 것을 확인할 수 있다.

 

GUI로도 쉽게 언스태이징을 할 수 있다.

 

 

4. 커밋 commit

그럼 이제 커밋을 진행해 보자.

test.txt와 simple_calculator.py 파일을 스테이징 하고 진행하겠다.

마찬가지로 CLI와 GUI 둘다 커밋이 가능하다.

※ commit을 하게되면 staging된 모든 변경사항을 적용하게 된다. 스태이징처럼 각 파일을 지정할 수 없다.

$ git commit -m "FIRST COMMIT"

커밋을 하게 되면 git status 명령어를 칠 때마다 나오는 No commits yet 문장이 사라진다.

커밋이 되었다는 말이다.

 

GUI에서도 A가 사라지고 아무 마크가 없는 것을 확인할 수 있다.

이는 정상적으로 commit이 완수 되었으며, 최종 파일로 결정 되었다는 의미다.

 

이제 GUI에서 커밋을 해보자.

우선 나머지 두개의 파일 my_adder.py, test.py를 스테이징 하자.

그 후 아래 그림처럼 메시지 창에 남길 메시지를 입력하고 커밋 버튼을 누르면 된다.

※ 레포지토리가 하나면 위 사진의 레포지토리 선택은 안 뜰 수 있다.

이런식으로 커밋을 올릴 수 있다.

git status를 확인하면 nothing to commit, working tree clean 이라고 작업 트리가 깨끗해서 commit할 게 없다고 뜬다.

 

이제 해당 리포지토리를 github에 올리면 된다. 올리는 부분은 5. push하기 에서 배울 것이다.

 

 

4-1. 커밋 되돌리기

커밋을 잘못했을 경우, 커밋을 되돌릴 수 있다.

우선 GUI 부터 보자.

이런식으로 마지막 커밋을 되돌릴 수 있다.

개인적으로 GUI가 좀 더 직관적으로 동작하는 것 같다.

GUI를 사용해 이런식으로 되돌리기를 반복하면 최초 commit 이전까지 되돌릴 수 있다.

 

이제 CLI의 경우를 알아보자

$ git reset HEAD^

이런식으로 git reset HEAD^ 명령어를 사용하면 commit을 취소하면서 직전 HEAD로 되돌아간다.

하지만 git reset HEAD^ 명령어로는 최초로 돌아갈 수 없다.

이런 식으로 에러가 발생한다.

혹시 원인을 아시는 분 댓글로 남겨 주시길 부탁드립니다 ㅠㅠ
아직 배움이 부족해 왜 이런지 알 수가 없네요..

 

 

5. Push로 원격 저장소에 올리기

Github repository에 업로드 하는 것을 Push라고 한다.

우선 git init으로 시작했기 때문에 연결된 github가 없다.

업로드 하기 위해서 깃허브 계정에 레포지토리를 생성해야 한다.

 

나는 내 계정에 test라는 레포지토리를 생성했다.

$ git remote add origin https://github.com/KayyoungHL/test
$ git push origin main

바로 push를 하려고 하면 pull을 먼저 하라는 경고가 나온다.

pull은 fetch+merge를 하는 명령어이다.

fetch는 대상 레포지토리의 정보를 받아오는 명령어고 merge는 fetch로 불러온 레포지토리와 내 local branch와 합치는 명령어다.

 

push 하려는 원격저장소에 pull 명령어를 사용해서 데이터를 업데이트 후 머지한다.

$ git pull origin main

위와 같이 연관되지 않은 기록을 갖고 있어서 머지를 거부한다는 명령어가 나온다.

이럴 경우 강제로 머지하는 기능이 필요하다.

 

강제로 머지하는 것은 일반적으로 권장되지 않는 방식이다.

하지만 이번의 경우, 만든 레포지토리이기 때문에 아무 데이터가 없다.

따라서 강제로 머지를 해주어도 문제가 발생할 가능성이 없어서 사용해도 된다.

$ git pull origin main --allow-unrelated-histories

이제 push가 가능하다.

push를 해보자.

 

$ git push origin main

이제 깃허브 레포지토리에 업데이트가 되었는지 확인한다.

이번 환경 구축 과정에서 두번의 커밋을 했는데 각각 메시지가

FIRST COMMIT와 SECOND COMMIT이다.

이런식으로 커밋이 잘 된 것을 확인할 수 있다.

 

이 작업 역시 GUI로 할 수 있다.

변경 내용 게시라는 버튼을 누르면 연결된 깃허브에 권한을 허용해달라면서 페이지가 뜬다.

페이지에 들어가서 권한을 허용해주면 push가 완료된다.

 

 

6. git history 시각화

Git History EXTENSION을 사용하면 훌륭한 깃 시각화를 볼 수 있다.

깃 히스토리 활용은 다음 포스트에서 보여줄 것!