😭 Git.. 그거 어떻게 쓰는 건데..
지금껏 소스트리 같은 GUI로만 Git을 사용해왔던 나는 CLI로 Git을 다루는 상황에 굉장히 난감함을 느꼈다. 그래서 CLI로 Git을 다루는 것에 익숙해지기 위해 Git의 기본 개념과 필수적인 명령어 정도를 정리해보고자 한다.
📂 Git이란?
지피지기면 백전백승. Git 명령어를 살펴보기 전에 먼저 Git이 무엇인지 알 필요가 있다. Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템, 혹은 이러한 명령어를 가리킨다. 보통 개발 관점에서 Git은 소스 코드의 버전을 관리하는 소프트웨어 정도로 생각할 수 있겠다.
❓ Git과 GitHub
Git의 개념에 대한 이야기를 할 때, GitHub를 짚고 넘어가지 않을 수 없다. Git과 GitHub를 혼동하여 오용하는 경우가 종종 있는데, 둘은 엄연히 다르다. 둘의 정의를 비교하면 다음과 같다.
💡 Git
: 로컬에서 소스 코드의 버전을 관리하는 소프트웨어
💡 GitHub
: 로컬의 Git 버전을 원격으로 관리해주는 클라우드 서비스
위의 정의를 보면 알 수 있지만 Git은 소프트웨어고 GitHub는 웹 서비스라는 점에서 일단 차이가 있다. 그러나 둘의 근본적인 차이는 저장 방식에 있다. 로컬에서 Git을 이용해 소스 코드의 버전을 관리하는 경우 로컬 컴퓨터의 데이터가 유실되면 당연히 소스 코드도 영향을 받는다. 이를 방지하기 위해 GitHub와 같은 클라우드 서비스를 이용하여 소스 코드의 버전을 원격 저장소에 저장해놓는 것이다.
🔩 Git을 파헤쳐보자!
무작정 Git 명령어를 살펴보기 전에 Git의 원리를 간단하게나마 살펴보면 이해가 더 쉬울 것이다.
위의 이미지처럼 Git의 영역은 크게 Working Directory, Staging Area, Repository의 3가지로 구분된다. 각각의 정의에 대해 간략하게 살펴보면 다음과 같다.
💡 Working Directory
: 현재 작업하고 있는 프로젝트의 로컬 디렉토리
💡 Staging Area
:
commit을 하기 위해add명령어로 추가한 파일들이 대기 중인 공간
💡 Repository
:
commit한 소스 코드들이 모여 있는 저장소
이를 바탕으로 실행 순서를 정리하면, 먼저 로컬에서 작성한 코드를 Repository에 등록하기 위해 add 명령어로 Staging Area에 올려놓는 1차 과정이 필요하다. 이후 최종적으로 Repository 등록을 위해 commit 명령어를 사용하면 된다.
그렇다면 굳이 Staging Area를 거쳐야 하는 이유는 무엇인가? 그 이유는 크게 3가지 정도로 정리할 수 있다. 간략하게 짚고 넘어가면 일부분만 커밋할 때, 충돌이 발생했을 때, 커밋을 다시 하고 싶을 때 Staging Area가 진가를 발휘한다. 이에 대해 자세히 설명한 글이 있어서 링크를 남긴다.
💡 Staging Area의 존재 이유
다시 Git의 실행 순서로 돌아와서, Git의 실행 순서에 따른 파일 상태를 살펴보고자 한다. 각각의 파일 상태를 간단하게 정의하면 다음과 같다.
💡 Untracked
: Working Directory에 존재하는 파일로서, 아직 Git으로 버전 관리를 하지 않은 상태
💡 Unmodified
: 새롭게 파일이 추가되어 아무런 수정이 일어나지 않은 상태
💡 Modified
: 추가한 파일을 수정한 상태
💡 Staged
: Staging Area에 반영된 상태
정리하면 Working Directory에서 add한 파일은 위의 4가지 상태를 순차적으로 거쳐서 Staging Area에 등록되고, 이는 곧 커밋할 준비가 되었음을 의미한다.
📢 Git 명령어
서두에서도 언급했듯 나는 소스트리 같은 GUI로 Git을 사용했었다. 하지만 원래 Git은 CLI 기반이다. 여기서 잠깐 간략하게 CLI와 GUI의 차이에 대해 설명하면 다음과 같다.
💡 CLI
: Command Line Interface의 약자
: 명령어와 같은 글자 입출력 방식
💡 GUI
: Graphic User Interface의 약자
: 그래픽, 아이콘 같은 그림 방식
CLI와 GUI는 둘 다 인터페이스, 즉 서로 다른 두 시스템 사이의 상호작용에 관한 용어이다. 다만 소통의 방식이 글자인지 그림인지에 차이가 있다.
컴퓨터와 사용자 사이의 인터페이스라는 관점에서 CLI, GUI를 본다면 이 글의 주제인 Git이나 명령 프롬프트 창이 CLI에 해당되고, 바탕화면의 아이콘이 GUI에 해당된다.
⭐ 이건 꼭 알아야 해!
이제부터는 Git을 사용하면서 꼭 알아야 할 명령어를 살펴보고자 한다.
$ git init
$ git init은 로컬 저장소를 만들고 싶은 디렉토리를 설정하는 명령어다. cd로 설정할 디렉토리로 이동한 후 명령어를 입력하면 된다. 이를 통해 디렉토리 하위에 보이지 않는 .git 디렉토리가 생성되고, 이 디렉토리에 소스 코드의 버전이 저장된다. 만약 .git 디렉토리를 삭제할 경우 저장해놓은 파일의 버전이 삭제되기 때문에 주의해야 한다.
$ git config user.name '사용자 이름' $ git config user.email '사용자 이메일'
$ git config는 Git 작업에 사용할 사용자의 이름과 이메일을 설정하는 명령어다. 만약 현재 시스템의 모든 작업에 해당되도록 하고 싶다면, config 뒤에 --global을 추가로 작성하면 된다. 사용자 이메일에 사용 중인 GitHub 이메일을 작성하면 push할 때 자동으로 커밋의 작성자가 GitHub 사용자로 연결되어 편리하다.
$ git status
$ git status는 현재 작업 중인 파일의 상태를 확인하는 명령어다. 이를 통해 앞서 살펴본 4가지의 파일 상태를 확인하고, 적절한 조치를 취할 수 있다.
$ git add '경로와 파일명'
$ git add는 작업이 완료된 파일을 Staging Area에 등록하는 명령어다. 이를 통해 저장소에 commit할 준비를 하게 된다.
$ git commit -m "메시지"
$ git commit은 Staging Area에 대기 중인 파일을 Repository에 커밋할 때 사용하는 명령어다. 메시지에는 파일의 변경사항에 대한 내용을 작성한다. 이를 통해 최종적으로 로컬 저장소에 수정한 파일의 버전이 등록된다.
$ git log
$ git log는 지금까지 한 커밋들의 로그를 살펴보고 싶을 때 유용하게 사용할 수 있는 명령어다.
$ git remote add origin '저장소 URL'
$ git remote add origin은 원격 저장소를 추가할 수 있는 명령어다. 이를 사용하기 전에 먼저 GitHub에서 Repository를 생성할 필요가 있다. 저장소 URL에 생성한 Repository의 주소를 작성하면 된다.
$ git remote -v
$ git remote -v는 추가한 원격 저장소의 목록을 확인할 수 있는 명령어다.
$ git push origin main
$ git push origin main는 로컬 저장소에 커밋한 파일을 추가한 원격 저장소에 반영하고 싶을 때 사용하는 명령어다.
$ git branch -m master main
$ git branch -m master main은 master 브랜치의 이름을 main으로 변경하는 명령어다. 이름을 변경하는 이유는 인종 차별 이슈에 있다. master라는 이름에서 인종 차별적 단어인 master & slave가 연상될 수 있기 때문이라고 한다.
😊 원리를 알고 쓰자!
지금까지 Git의 개념과 명령어에 대해 정리했지만, CLI가 익숙하지 않은 탓인지 아직도 좀 어렵다. 하지만 익숙하지 않기 때문에 느끼는 어려움은 자주 접하면 충분히 극복할 수 있으리라 믿는다. 어차피 개발자로서 코딩 작업을 할 때 수도 없이 보고 쓰게 될 명령어들이기 때문에 계속 사용하면서 익숙해지려고 노력해야겠다.
그리고 정리하면서 인상 깊었던 점 중 하나는 master 브랜치 이름을 main으로 바꾸는 정책이다. 영어권 화자가 아니라서 그런지 생각지도 못했던 부분인데, 문화적 맥락을 이해하면 충분히 불편하게 느껴질 수 있다는 생각이 들었다. 앞으로 개발을 하면서도 서비스가 누군가에게 불편함을 유발하지는 않는지, 차별로 느껴지지는 않는지 끊임없이 고민해야겠다고 오늘도 다짐한다.
🙏 출처
https://subicura.com/git/
https://www.hahwul.com/2021/07/17/changing-the-github-default-branch/
https://iseunghan.tistory.com/321?category=1011511
