[데브코스 TIL] Day 3 - Github를 활용한 원격 코드 관리 - 웹 풀 사이클 데브코스 TIL

'23.11.16(목) 웹 풀 사이클 데브코스 TIL

Github 연동과 자주 쓰는 명령어

오늘은 Github repo를 로컬 환경과 연동하는 과정과 그 사이에 자주 사용되는 명령어에 대해 학습했다.

🖥️ 파일 추적

지난 시간에 git init 명령어를 통해 프로젝트 폴더를 git 저장소로 초기화하는 방법에 대해 알아보았다.

GitTest 라는 디텍토리에 text.txt 라는 파일을 만든 뒤,
git status 명령어로 현재 git 저장소의 상태를 확인해보자.

Untracked files 라는 목록에 text.txt라는 파일이 있고,
Track 하려면 git add를 사용해 보라는 힌트를 제공하고 있다.

근데 파일을 Track 한다는 것이 어떤 의미인가?

Git 저장소로 초기화한 프로젝트 폴더 내의 파일들은 두 가지 상태로 분류된다.

• Tracked File
  -> 디렉토리 내 파일이 Git에 의해 관리되고 있는, 또는 관리될 파일
  -> 파일들의 상태를 Git에 의해 추적되고 있다는 의미
  -> Tracked File은 Unmodified(변동사항 x), Modified(수정됨), Staged(Stage 된 상태)

• Untracked File
  -> Git에 의해 추적되지 않고 있는 파일
  

그럼 어떻게 파일을 추적하는가?

위에서 Bold처리된 Stage의 개념을 이해할 필요가 있다.

로컬 저장소에 처음 추가된 파일은 기본적으로 Untracked 상태이다.

이때
git add [파일명] 라는 명령어를 사용하면

add한 파일들이 Staging Area에 속하게 된다.

Stage는 공연 예술에서 배치, 배열, 준비 등을 수행하는 의미로 사용되고
Git에서는 "다음 커밋에 포함되기 위해 준비한다." 정도로 해석할 수 있다.

커밋은 프로젝트의 현재 상태의 Snapshot을 찍어내 버전을 만드는 명령 정도로 볼 수 있다.
간단하게 이해만 하고 자세한 내용은 후술하도록 하겠다.

아까의 상태로 다시 돌아와

git add text.txt 명령어를 입력하여 text.txt를 추적해 보겠다.

파일 이름의 색깔이 초록색으로 바뀌며
Untracked File에서 Changes to be committed의 목록으로 변경된 것을 확인할 수 있다.
말 그대로 커밋할 준비가 되었다는 것이다!

git commit + 커밋 메시지 로 커밋을 수행할 수 있는데,
커밋 메시지는 커밋할 버전의 변경사항을 작성할 수 있다.

커밋을 하려면 커밋의 주체를 지정할 수 있도록 사용자의 정보를 입력하도록 하는데,
--global 옵션을 이용해 지정하면 최초 입력 시 다른 Git 저장소의 커밋에도 자동으로 적용된다.

커밋 메시지를 입력하는 방법은 여러 가지가 있으나,
git commit -m "[커밋 메시지]" 방법이 가장 보편적일 것이다.

git log로 로그를 찍어보면
고유한 커밋 id와 작성한 커밋 메시지를 확인할 수 있다.

🤹🏻‍♂️ GUI로 Git 저장소 관리하기

이제 우리는 명령어 입력 한 번 없이 위의 일련의 과정을 수행할 수 있다.

우리에게 익숙한 VS code에서 바로 수행할 수 있는데,

좌측의 Source Control 탭을 들어가면
친절하게 저장소(Repo)를 초기화 할 수 있도록 알려준다.

아까 만들었던 것처럼 텍스트 파일 생성 후 다시 소스 컨트롤 탭에 들어가면,
어떤 부분이 추가되었는지, 수정되었는지, 삭제되었는지를 비교할 수 있고

변경사항이 있는 파일의 리스트를 볼 수 있다.

+ 버튼을 클릭했을 때 파일의 이름이 Stage Change 영역에 들어갔고, 오른쪽에 U - Untracked
상태가 A - Added 로 변경되었음을 확인할 수 있다.

커밋메시지를 입력 박스에 적어 넣고 Commit 버튼을 클릭하면-

이제 아무것도 안보인다! 아마 커밋이 됐겠지?

내친김에 로그도 GUI로 보도록 하자

Git History라는 확장프로그램을 설치한 뒤 소스 컨트롤 탭을 다시 가면

좌측 상단 시계 버튼을 클릭하면 커밋 로그를 볼 수 있고, 세부 사항도 확인할 수 있게 된다.
너무 편하잖아!

하지만 언제까지나 GUI는 우리의 편의를 위해 도움을 주는 것일 뿐, CLI로 동작을 수행하는 방법과
원리는 정확하게 알고 있어야 한다-!

👼🏻 Github

우린 지금까지 Git의 Local VCS 로서의 동작을 수행해 보았다.
이제 Github를 통해 분산 VCS의 기능까지 확장해보자.

Remote Repo를 만들어 Local 환경으로 가져오고,
Local 환경의 프로젝트를 서버 환경으로 연동해보자.

Github에 가입하고 Create New Repository 버튼을 통해
GitTest라는 이름의 서버 Git 저장소인 Remote Repo를 만들었다.

처음 Repo를 열면 친절하게 시작할 수 있는 튜토리얼을 제공한다.

그 중
git remote add origin https://github.com/sodlfmag/GitTest.git

라는 명령어로 나의 remote repo를 로컬 환경으로 가져올 수 있다.

git remote add [repo 이름] [git repo URL]
명령어의 용법은 다음과 같다.

튜토리얼에서는
git remote add origin https://github.com/sodlfmag/GitTest.git

으로 나와있는데,
기본적인 repo 이름이 origin으로 설정되어 있기 때문이다.

필자는 Jin이라는 이름을 붙여 내려받아 보도록 하겠다.
git remote add Jin https://github.com/sodlfmag/GitTest.git

git remote -v 라는 명령어를 통해 현재 프로젝트 폴더에 있는
git repo의 이름과 URL 을 확인하면

Jin 이라고 설정된 것을 확인할 수 있다.

지금까지의 작업이 Remote Repo를 Pull 해 오는 과정이었다.

현재 Remote Repo는 처음과 같이 빈 상태이다.

git push ([repo 명]) ([branch 명])
이라는 명령어를 통해 현재 로컬 버전을 서버에 연동하는 작업을 수행하는데,
현재 branch에 push 연동을 한다고 하면 branch 명을 생략할 수 있다.

현 상태에서 정보를 명시해 git push Jin main을 입력하면 바로 연동이 되지만,
git push로만 push하는 방법을 살펴보자.

git push를 최초로 수행하면 위와 같은 오류가 발생한다.

생략된 정보에 의해
현재 로컬에 내려받은 Jin이라는 원격 저장소의 main branch와
현재 작업중인 local 저장소와의 연결관계를 잡아주는 명령이 필요하다.

git push --set-upstream Jin main
git push -u Jin main

같은 작업을 수행하는 명령어이다.

이제 local의 main branch가 Jin/main branch를 추적할 수 있게 되었다.

이제부턴 커밋 후에 git push 만으로 Jin/main branch에 push할 수 있게 되었다.

깃허브의 Repo에 로컬 버전이 push된 것을 확인할 수 있다.