Git이란?
VCS Version Control System 으로 버전을 관리해주는 시스템입니다. 게임을 해보셨던 분들이라면, 버전시스템은 친숙하실겁니다! 웹 앱,게임 등과 같은 소프트웨어들의 버전을 관리할 수 있습니다.
버전은 'x.x.x'로 나타내는 데, 'major.minor.patch' 이렇게 생각하면 됩니다. 예를들어서, 1.0.0 ->2.0.0 으로 갔다 ? 대격변이 일어난 메이저 패치, 1.0 -> 1.1로 갔으면 마이너 패치, 1.0.1 ->1.0.2 로갔다? 사소한 변경입니다.
Git을 꼭 써야하냐? 라고 물어본다면 필수는 아닐 수 있습니다.
전 이렇게 생각합니다. 휴대폰 , 컴퓨터, TV,세탁기 ,냉장고 등 없어도 사람은 살려면 살 수 있습니다. 하지만, 안쓰면 99.9% 삶의 질의 하락을 경험할 수 있습니다. 개발자의 삶의 질을 위해 쓰는게 좋습니다.
Git을 다루어야 하는 이유
Git은 버전을 관리합니다. 그렇다면 버전을 다룸으로써, 얻는 이득이 뭐가 있을까요? 생각을 해봅시다! 소프트웨어는 시간에 따라서 점차 발전시켜 나갈 수 있다는 장점을 가지고 있습니다. 그리고, 만약 최초 버전 배포 시, 오류가 있다면 빠르게 고쳐야 하겠죠! 이러한 과정을 유지/보수라고 합니다.
이처럼, 소프트웨어는 시간의 흐름에 따라서 변할 수 밖에 없고, 꾸준히 유지관리를 해주어야 합니다. 2013년도의 리그오브레전드와 2023년도의 리그오브레전드는 완전히 다른 것처럼 말이죠!
즉, Git은 이러한 시간에 따른 변화를 좀 더 쉽게 관리하게 해주는 도구입니다.
Git을 쓰지 않더라도, 시간에 따른 변화는 충분히 대응가능 합니다. v1->v2로 업데이트를 한다면, v1원본을 우선 백업한 뒤(압축) , v1을 카피해서 , 업데이트 한 다음 다시 출시하면 됩니다.
Git과 기존 백업 방식의 차이
하지만, 이렇게 되면 점점 백업하는 용량이 커질 것이고, 사소한 변경을 했을 때 모든 프로젝트 파일을 사본으로 갖는건 또 애매하고 , 그렇다고 원본을 보관하지 않고 그냥 수정했다가 안돼면 대참사이고..와 같은 고민을 Git은 해결해줍니다.
위처럼 Git은 .git 파일에 수정사항을 잠시 저장한 뒤, 이 수정사항이 맞는거 같으면 최종 업데이트 시키는 방식입니다. 그래서, 중간에 수정사항을 반영하는 걸 취소할 수도 있습니다. 물론, 고양이가 실수로 패치버튼을 눌렀어도, 옛날 버전으로 되돌리는게 가능하기 때문에 안정적인 서비스를 보장해줍니다.
그리고, .git파일 한 개를 갖고 있는게 여러 개의 큰 프로젝트 백업파일을 갖고 있는 것보다 좋겠죠!
물론,큰 기업의 큰 서비스들은 백업도 철저하게 할 것입니다. 하지만, 패치가 빈번한데 그때마다 패치하는 것 보단 보관 갯수가 훨~씬 줄어들겠죠. 즉, 공간적으로도 절약이 됩니다.
하나의 패치가 누가 수행했고, 어떤 변경 사항이 있었다는 걸 알게 된다 == 에러코드 찾기가 쉬워진다라는 장점도 있습니다.
Git 설치
https://git-scm.com/
git은 공식홈페이지에서 다운로드 받을 수 있습니다. 각 OS별로 설치방법이 나와 있으므로, 참고해서 받으시면 됩니다. 저는 Window이기 때문에, 설치파일을 받아서 쭉 설치했습니다!
WSL2와 WebStorm 연결하기
Git을 설치하면, Git bash라는 것과 함께 줍니다. 혹시, 컴공이신 분들은 알겠지만 bash shell할 때, 그거 맞습니다. Window는 Linux 커맨드를 칠 수 없고, Terminal환경이 좀 불편하기 때문에 WSL2로 Git을 다루는게 좋습니다.
WSL2
Window SubSystem Linux로, Window에서 Linux shell을 쓸 수 있게 해줍니다. Window 로컬 PC를 그대로 가상화시켜 Linux에 넣은 것 같은 환경을 만들어줍니다.
IDE(개발환경)과 연결하기
vscode를 쓰다가, 최근에 WebStorm으로 넘어오게 됐습니다. WebStorm에서 WSL2를 터미널로 쓰는 방법은 WebStorm Docs에 있더군요! Install Node.js and npm 파트부터 따라하시면 됩니다. 주의점이 WSL내에 Node를 깔라는 겁니다. Local 환경에 Node를 까는게 아닙니다!
git 초기설정
이렇게 Git을 설치하고, Git과 IDE를 연결했다면 아래와 같은 설정을 추가로해주면 더 윤택하게 Git을 쓸 수 있습니다.
autoctrlf , filemode
Window를 쓰는 사람들에게는 쫌 중요한 설정이다. Git으로 관리되는 소스코드들은 추후에 GitHub과 같은 원격저장소로 공유하게 되는데 , 이때 OS에 구애받지 않게 해주는 속성들이다. (Window라면, 필수적으로 설정해주자.)
개행문자가 window는 /r\n인데, \n만 있도록 해준다. 또, \n만 있을 때는 , /r를 붙여서 github에서 가져온다.
git config --global core.autocrlf true
Window는 파일권한이 자주 왔다갔다 거립니다. 관리자 권한으로 실행하시겠습니까?라는 말을 자주 봤을겁니다. Git은 Filemode도 검사하기 때문에, Filemode변경도 변경이라고 인식합니다. WSL에서는 꺼줍시다.
git config --global core.filemode false
name ,email 설정하기
사용자를 등록합니다.
global config --global user.name '이름'
이메일을 등록합니다.
global config --global user.email '이메일'
처음 접근하는 branch 변경
처음깔면, Git Branch가 Master일겁니다. 요즘은 Main이 루트 Branch이기 때문에, 변경해주면 좋습니다.
git config --global init.defaultBranch main
명령어 모음
git config --global core.autocrlf true
git config --global core.filemode false
global config --global user.name '이름'
global config --global user.email '이메일'
git config --global init.defaultBranch mainGit의 개념 (Work Flow)
위에서는 추상적인 개념을 설명했지만, 이제 제대로된 용어로 Git을 파헤쳐 볼 겁니다. Git은 버전관리를 위해서 3가지의 영역으로 나누어 폴더를 관리합니다.
각각의 영역에 대한 설명은 나중에 하도록하고 예시를 보면서 자연스럽게 각각의 영역이 어떤 역할을 하는지 체화하는게 좋습니다.
우선, /dev/fishingProject라는 sharkkk가 먹이가 부족해서 시작한 생존프로젝트가 있다고합시다. 거기에는 물고기 데이터인 Fish.txt , 낚시를 자동화시킨 fishing.ts와 로그기록인 fish.log가 있다고 합시다. 그러면, Work Space에 아래와 같이 존재하게 됩니다.
- Workspace 즉 ,내가 작업하고 있는 공간을 이야기합니다. 개발폴더를 가리킵니다. 여기 안에 있는 파일은 특정시점의 파일들입니다. 그래서, 이 파일들을 'snap shot'이라고도 합니다.
이때, shark는 오늘 낚시를 끝내고 log를 저장하려고 합니다.fish.log는 staging Area에 우선 들어갑니다. 이 Staging Area는 최종 저장을 하기 전, 준비단계라고 생각하면 됩니다. 그래서, 중간저장하는걸 Caching이라고 하는데, cache라고도 합니다.
fish.log는 하루가 지났기 때문에 더 이상 수정사항이 없다고 생각해서 확정을 지었습니다.
이 과정을 Commit한다고 합니다. 커밋 많이 들어보셨죠! git repository에는 commit기록이 남게됩니다. 즉, git repository에는 우리 폴더의 변화된 History가 쌓이게 됩니다. 이걸로, 전버전으로 돌리는 등이 가능해집니다.
역과정은 Reset(git repo->stage) , rm --cached(stage->workspace)라고 합니다.
git add
Workspace에 있는 파일들을 stage에 올립니다. 이때, 폴더에 있는 특정파일을 업로드하고 싶으면, git add <파일명> 명령어를 실행하면 됩니다. 와일드 카드가 사용가능하기 때문에, git add *.txt와 같이 모든 txt파일을 업로드와 같은 명령어도 됩니다. 하지만 제일 많이 사용하는 명령어는 아래일 겁니다.
git add . : gitignore에 있는 파일 제외하고 모두 업로드
git은 수정된 파일/기존에 없던 파일만 , Staging 파일로 갑니다. Modified된 파일을 track영역에 있다고하는데, 넘어갑시다.
git status
위와 같은 Git의 진행과정을 보기 위해서, Git status라는 명령어도 매우 많이 씁니다.
보통은 ,git status -s와 같이 짧은 명령어로 봅니다.
빨간색은 Statge에 없는 파일이고 , 초록색은 기존 git stage에 있는 파일이다.아래의 status에서 b.txt는 기존에 있는 파일이지만, 수정이 되었기 때문에 다시 stage에 업데이트가 필요하다라는 뜻이다.
git ignore
코딩을 하다보면, 알겠지만 민감한 파일들 DB 계정,비밀번호 서버 접근 계정,비밀번호와 같은 민감한 정보가 있을 수 있다.그리고, 굳이 git에 기록하지 않아도 되는 정보들도 있다. 따라서, 그런 파일들을 지정할 수 있도록 git은 .gitignore이라는 파일을 만들어서 무시할 수 있도록 지원한다.
.ignore 플러그인
gitignore은 초보자라면 뭐를 숨겨야하는지, 뭐를 숨기면 안되는지 애매할 때가 많다. 따라서, 플러그인을 잘 이용해보도록하자. 나는 webstorm에서 .ignore를 이용해줄 것이다. 개발자들이 필수적으로 .gitignore에 넣는 대부분의 파일들을 자동으로 지정해준다. 물론, 프로젝트에 따라서 유동적으로 변경해주어야 한다.
git diff
git diff는 기존 git에 있는 stage에 있는 파일과 workspace에 있는 파일의 차이를 보고싶을 때 쓸 수 있다. 읽는법또 꽤 직관적인데, a/b.txt라는 말은 기존 파일 vs 스테이지에 있는 파일이라는 뜻이다.
지금 stage에 있는 파일에서 a.txt는 hello가 없어졌고, b.txt는 hello,hellowww,안녕하세요가 추가되었다는 뜻이다.
git commit
stage에 있는 것을 확정시키는 단계이다. 이 과정이 중요한데, message를 잘 달아줘야한다. git message를 의미없게 update1 ,update2라고 하기보단, Add Login Module,Add payment Service와 같이 의미있는 단위로 commit 메세지를 남겨주는게 좋다.
메세지를 추가해서 커밋을 한다.
git commit -m "message"
workspace에서 staging 과정을 뛰어넘어 모든 것을 commit한다.
git commit -am "message"
git log
commit Message와 누가 Commit을 했는지 볼 수 있는 명령어이다. 주로, git shortlog로 짧게 보는 경우가 많다. 아래처럼 나왔다면, 2개의 커밋을 날렸다고 볼 수 있다.
이제, 로컬에서 할 수 있는 Git에 대해서는 모두 다룬것 같다. 이제 이 Git을 여러명이서 쓰기위해서 GitHub과 연결하면서 생기는 문제들을 다루면서 기본적인 git은 마무리 지으려고 합니당!
