git 활용 step 1st / 혼자서 백업용도로 사용하기

Introduction

git은 단순히 협업 툴? 이런 용도로 다들 인식하지만 난 혼자서 맨땅에 대가리 박으며 공부를 한 터라, 사실 협업이란게 무의미했다.
그래서 맨처음엔 아예 시작도 안했는데 어느순간 필요성이 느껴진 이유가, 바탕화면에 코드 파일들이 아주 더럽게 넘쳐나서부터이다. 재사용되는 코드가 있는데, 계속 뭔가 덧붙여져서 원본 파일 찾기도 매우 힘들었음.
참고로 난 깃을 코딩을 시작한지 약 1년? 정도 지나서야 깃을 깔짝깔짝 만져봤던것같다.

사실 포스팅을 읽으면 왜 이런 기본적인걸 포스팅까지하지? 라는 의문점이 들테지만 나도 예전에 깃을 처음 접했을때, 굉장한 이질감을 느꼈던 이유가 왜써야하는지 잘 못느꼈기때문이었음. 떄문에 과거의 나같은 코찔이들을 위해 포스팅을 할거다.

때문에 활용방법 위주로 포스팅하려고 한다.
이번 포스팅 주제인 백업용도로 사용하기는 내가 거의 3년정도동안 계속 쓴 방법& 지식수준이다. 
최근들어 취직준비하니까 협업용, 브랜치 등을 포스팅 시리즈에 포함했지만 내 깃레포들 보면 브랜치조차 없는걸 확인가능하다. 진짜 이 포스팅 내용정도의 git 지식으로만 코딩을 3년동안함..
혼자 코딩하면 깃을 백업용으로만 쓰는것으로 충분하다고 생각한다.

주 활용도는
1. 백업용으로 코드 보관하는거
2. base템플릿 저장용
이렇다. 

---

 

깃으로 관리하는 폴더로 지정하기 - .git

 

일단 깃을 설치하고 이런건 포스팅들이 넘쳐나니까 제쳐두고,

내가 원하는 디렉토리를 깃으로 관리하려면 설정을 해야한다.

pwd

현재 git-step1-posting이라는 디렉토리에 있다.

ls

현재 mycode.js라는 파일 하나가 존재함. 좀따 쓰려고 만들어둔거임

이 디렉토리를 깃으로 관리하는 디렉토리로 만들려면

git init

이명령어를 쳐야한다. 물론 깃이 설치되어있어야함.

 

ls -al

설치후 다시 파일 목록을 숨김파일까지 전부 뜨게 확인해보면

이렇게 .git이라는 디렉토리가 생긴걸 확인할 수 있다.

이제 git-step1-posting 디렉토리는 git으로써 관리할 수 있는 디렉토리가 되는거다.

 

 

# 왜 이런걸 코드 하나하나 설명하는거임?

git clone 레포지토리주소

아래에 쓸 기능인 clone으로 내 레포의 react base를 통쨰로 가져와보면, 

얘도 .git이라는 디렉토리가 존재한다. 

근데 내가 이 코드에 나만의 코드를 덧붙이고 수정해서 다른 레포지토리에 내 커스텀 코드들을 따로 저장해서 관리 하고싶다면?

이전에 있던 커밋들도 싹다 지워졌으면 좋겠고..

그렇다면 

rm -rf .git

으로 이 디렉토리를 통째로 삭제한 후

git init

을 치면 다시 새로운 .git디렉토리가 생기고 새로운 git으로 이 디렉토리를 관리하겠다고 해줄수 있다.

 

깃때문에 오류생기고 귀찮아지면 그냥 저 .git 디렉토리 통째로 지워주면된다.

그럼 아예 깃으로 관리안하는 디렉토리가 되어버린다는것.

그냥 컴퓨터 뻑나면 재부팅하는거라고 생각하면 됨. 여기에 git init을 쳐서 새로운 깃으로 관리하게해서 새로운 레포에 넣거나 할 수 있다는거임.

참고로 깃을 처음배울때 뭔ㅅㅂ 이런 개똥같은걸 좋다고 배우라고 하지? 할정도로 오류가 많았는데, 이걸 알았다면 디렉토리 한 100개는 덜 만들었을듯 하다.

참고로 .git이 여러개 있으면 에러뜨는경우도 있다. git init을 난사해버리면 얘가 에러 엄청 띄움. 이럴떄 이 개념을 알고있다면 해결이 가능하겠지?

 

 

 

디렉토리 변화 기록하기. add, commit

add는 스테이징이다, commit은 스테이징된 기록들을 기록하는 지점이다 이러는데, 다필요없고

그냥 이거 add, commit 두개 쌍으로 같이다닌다고 생각하면 됨.

git add .
git commit -m 'first commit'

이렇게 쓰면 된다.

(이렇게 같이 쓰는데 누구는 이거 귀찮아서 아예 두 명령어 한번에 쳐주는 bashrc파일같은거 수정하고 하는사람도 있음.)

그만큼 그냥 달고 살아야 하는 커맨드다.

이거 치면 그냥 현재 깃으로 관리하는 파일들 상태를 기록하겠다 라는 말이다.

그래도 양심상 조금 설명을 붙이자면, add다음에는 디렉토리나 파일을 특정해서 해당 파일들을 스테이징하겠다는건데, 그냥 쩜 으로 쓴건 모든 디렉토리 파일 다 스테이징 하겠다는거임. 쩜으로 걍 전체 스테이징하고, 스테이징하기 싫은건 그냥 git ignore파일로 관리하면 된다. 그냥 'add .' 으로 다 하면 된다는거임.

 

commit을 치면, 이렇게 뭐가 뜨는데, 이전 커밋과 비교해서 몇개의 파일이 변했고 빠졌는지 간략하게 소개해줌

 

 

# 해볼까?

console.log("hello muzzi");

mycode.js라는 파일 내용이었고 first commit에서 커밋이 된 상태이다.

console.log("hello muzzi");
console.log("pig muzzi");

이렇게 pig muzzi라는 코드를 추가해서 다시 add commit해보자

git add .
git commit -m 'second commit'

이렇게 또 한개의 파일이 수정됐고 한줄이 추가됐다고 기록이 뜸.

참고로 난 이렇게 source control branch라는 vs코드? 익스텐션이었나? 암튼 이걸로 확인하는데, 시각화해줘서 나름 유용하다. diff 이런 이상한 명령어 배우지말고 그냥 익스텐션 깔고 사용하는게 정신건강에 매우 이롭다..

 

 

 

 

# 이전 commit으로 돌아가려면?

난 사실 거의 안썼다.. 3년정도 코딩하면서..

거의 개인프로젝트다보니 틀린부분을 어떻게든 코드를 노려봐서 찾아내서 고쳤었음..

그래도 알아낸 방법을 간단하게 소개하자면

 

현재 second commit을 한 상태인데 난 first commit으로 돌아가고싶다. 

git log

돌아가려는 commit의 해시문자열을 알아야한다. git log명령어를 치면 알아낼 수 있음.

저기 체크한 문자열이 해시문자열이다.

난 vs코드 익스텐션을 쓰기때문에 저기 그래프에서 원하는 커밋에 마우스올리면 저렇게 해시문자열 복사할수 있게 되어있음.

커밋에 대한 아이디같은거임.

 

git reset --hard <해시문자열>

이렇게 하면

아까 second commit할때 추가된 pig muzzi라는 코드는 사라지고

second커밋 또한 깃그래프에서 사라진걸 확인 할 수 있음.

 

--hard옵션을 붙여서 아예 기록자체에서 사라져버린거다. 복구못함.

난 그냥 남자답게 --hard옵션을 붙이는데 다른 방법들이 더 있다. 알아서 찾아보도록..

(사실 몇번 되돌아갔다가 충돌 졸라나서 코드 통쨰로 날아간적이 많아서 겁나서 못함 ㅠㅠ)

 

 

 

 

 

백업을 해보자 / github

깃은 그냥 로컬에서만 쓰기에도 좋지만, github이 있기에 git이 존재한다고 생각한다.

깃허브라는 오픈 스토리지같은 서비스에 아예 내 코드를 통째로 저장 할 수 있다. 그러면 내 컴퓨터가 터지거나 다른컴퓨터에서 내 코드를 갖고오고싶을때 갖다 쓸 수 있을거다. 그냥 단순 파일저장하는 스토리지 서비스라고 생각해도되는데 코드에 특화되어있는게 장점이다. (물론 단순 스토리지 서비스라기보단 cicd를 돕는 git action이라던가 다양한게 많기는 하다. git의 세계는 무궁무진함)

GitHub · Build and ship software on a single, collaborative platform

회원가입하고 레포지토리를 만들어보자.

레포지토리 이름을 잘 정해두고, 퍼블릭으로 만들겠다.

(난 중요한 코드는 private 레포지토리로 만들고 나만 push pull clone할 수 있게 해놨음.)

암튼 만들면,

이렇게 레포지토리가 생성되는데, 저 주소를 복사하면 된다. 아니면 그냥 주소창에 주소 같다 복사해도됨.

 

이제 vs코드로 돌아와서 내 로컬에서는 깃허브에 push할 수 있도록 깃허브 계정으로 로그인을 해야한다. 사실 그냥 push하려고 할때 알아서 로그인 하는거 잘 되어있던걸로 기억함. 다른 똑똑한 개발자들이 넘쳐나게 포스팅해놨으니 여기엔 따로 적지 않겠다.

 

로컬컴퓨터에 github계정이 로그인되어있어야 백업용 push가 가능하다.

 

 

이제 remote 명령어를 써볼건데, 

git remote -v

 

아무것도 안뜬다. 

remote명령어는 깃허브주소를 저장해놓는 용도로 쓰는건데, .git파일마다 저장할 수 있다.

remote에 아까 복사한 레포지토리 주소를 넣어보자.

git remote add <단축어이름> <아까 깃허브 레포지토리 url>

이런식으로 할 수 있다.

git remote add muzzi-repo https://github.com/nurdworker/git-step1-posting.git

난 이렇게 muzzi-repo라는 단축어로 해당 레포지토리 url을 지정했다.

git remote -v

다시 -v옵션으로 목록을 보면,

저렇게 추가된걸 볼 수 있음.

이제 git 명렁어에서 저렇게 긴 url을 안갖다 쓰고 단축어로 쓸 수 있음.

모르겠으면 그냥 url로 계속 써도된다.

git push <remote 단축어이름> <브랜치이름>

이제 이 명령어를 써보자.

git push muzzi-repo main

저렇게 뭐가 쭈르륵 뜨는데 잘 push됐다는거다.

다시 github주소로 들어가서 아까 만든 레포지토리를 들어가보면

내 mycode.js라는 파일이 레포지토리에 잘 추가된걸 확인 가능하다.

브랜치는 사실 혼자서 개발하는거라 걍 매번 main으로 헀었다.

(master였던 시절도있었음. 노예계급 연상된다고 main으로 바뀐걸로암ㅋㅋ)

remote단축어는 보통 origin으로 많이 설정한다.

 

 

 

 

github에 넣어둔 코드 갖다 쓰기 - clone

 

 

이제 내 코드를 잘 넣어뒀으니 이 코드를 갖다 쓰는걸 해보자.

vs코드로 git-step1-posting-clone이라는 디렉토리를 만들었다.

이게 커맨드를 키고 clone명령어를 쳐보자

git clone <레포지토리주소>

단순하다.

git clone https://github.com/nurdworker/git-step1-posting

아까 push한 repository를 clone했다.

 

git-step1-posting이라는 디렉토리가 생겼고

 

mycode.js파일이 잘 들어있는걸 확인가능하다.

매우 단순하지?

 

# .git파일도 같이 받아오나?

받아오네?

소스패널에서도 이전 디렉토리에서 커밋해놨던 커밋기록이 통쨰로 받아왔다. .git디렉토리도 통쨰로 가져왔기때문임.

위에서 썻듯이, 커밋기록이있으면 해당 커밋으로 돌아갈수 있다.

혹시나 민감한 정보가 들어가있는 commit을 했다가 지우고 다시 commit했다고 하더라도, 

공개 레포지토리는 누구나 clone할 수 있다. 즉 민감한 파일이 있던 commit으로 돌아가서 탈취할 수 있다는 소리임.

때문에 해당 커밋 기록을 지우거나 아예 레포지토리랑 .git디렉토리를 통째로 지워버리고 다시 push하는게 안전하다.

이런 구조로 이해할 수 있음. push는 백업, clone은 restore같은 느낌?

어떤식으로 사용하니?

제목부터 백업용이라고 써두는데, 진짜 백업용으로 자주 쓴다.

만약 내 프로젝트를 새로운 컴퓨터나 vm에서 런타임으로 돌리고싶을때 github에 저장해둔 코드 통쨰로 가져와서 코드를 실행하는 식으로 말이다. 이건 뭐 다들 쓰는 방식일테니까 대충 이정도로 쓰고,

 

또하나의 활용방법은 (개꿀팁임)

base라는 레포지토리를 만들어둔다.

예를들어 front는 react, backend는 nodejs express로 돌아가는 투티어구조의 프로젝트를 만들고 싶다.

근데 이전에도 이미 이런 구조로 프로젝트를 진행했었다.

 

프론트 백 서로 api통신 프록시 설정, 단축어설정 다 되어있고, 뭐 필요한 모듈 패키지 동작되는 코드 추가되어있고 뭐 이런식의 내가 직접 짠 재활용이 가능한 코드를 base레포지토리로 지정해놓고 해당 프레임워크나 언어로 새로운 프로젝트를 만들고 싶은데, 이 작업을 매번 설치하고 코드 다시 짜고 할필요가 base레포지토리를 만들어두면 바로생략가능함.

이런 그림형식으로 하는거임.

이러면 매번 프로젝트 할때마다 새로 설치 다 하고 코드 서로 동작되게 셋팅하고 할 필요가 없는거다.

템플릿식으로 활용을 한다는거임.

매우 매우 유용하다.

pull은 뭐야 그럼?

 

참고로 백업용으로만 쓸거면 pull따위 안배워도됨.

암튼 git step1-posting-pull이라는 빈 디렉토리를 만들었다.

이제 여기서 pull을 해보자

git pull <레포지토리주소>

깃 레포지토리가 아니라고 안되네? 그럼 .git디렉토리를 만들어야지..

git init

.git 디렉토리 생성해주고,

 

git pull https://github.com/nurdworker/git-step1-posting.git

이제 잘됐다.

 

이번엔 mycode가 .git파일 있는데에 그대로 mycode.js파일이 받아와졌다.

clone은 레포지토리 이름 그대로 디렉토리를 통쨰로 복사해서 가져오고, pull은 현재 디렉토리에 해당 레포지토리 안에있는 데이터들을 가져온다.

사실 이건 중요한게 아닌거같고,

어? 그럼 그냥 레포지토리 코드 가져오는거 똑같은거 아냐? 뭐가다른데?

 

아래 상황을 보자.

원래 git-step1-posting디렉토리에서 new code라는 코드를 추가해서 github에 push해보자

 

git add .
git commit -m 'pull clone test'
git push muzzi-repo main

 

잘 push됐다.

깃허브에도 잘 반영된것같고

 

이제 아까 만든 두 디렉토리에서 이 변경사항이 적용된 코드를 내 코드에 적용시키고싶다. new code가 추가되기전에 clone과 pull을 했으니 github레포지토리에서 해당 데이터가 담긴 파일을 가져와야한다.

 

 

# 먼저 clone으로 변경된 코드를 가져오려고하면?

아까 git-step1-posting-clone디렉토리에서 하려하는거임

git clone <레포지토리주소>

이미 프로젝트 파일이 있다고 clone이 안된다.

아까 git-step1-posting디렉토리가 생기고 안생기고의 차이다.

즉 기존 내 코드에 변경사항이 적용된 레포지토리를 못가져온다는 소리임.

 

# 그럼 pull을 해볼까?

git-step1-posting-pull디렉토리에서 pull로 가져와보자

잘 동작되는데?

추가 되었던 new code도 제대로 적용댔다.

 

즉 clone과 pull의 차이는 clone은 최초에 받아올때 통째로 가져온다. 디렉토리 그자체로 가져오는거임.

그래서 변경된 github레포지토리의 변경사항을 가져오려고 clone하려고하면 안됨. 걍 처음 가져올때 쓰는 명령어다.

pull은 같은 깃으로 관리되는 프로젝트 폴더에서 업데이트된 github의 코드를 반영하려고 할때 쓰는거다.

때문에 .git디렉토리가 존재해야한다는것.

 

 

# clone한 디렉토리에서는 그럼 수정사항 반영못하니?

아니다. 내가 그림을 헷갈리게 그려서 혼동할수도 있는데 clone한데서 레포지토리의 업데이트된 커밋 적용하려면

걍 clone한 폴더에 들어가서 (.git이 있는 위치) pull땡기면 된다.

cd git-step1-posting/

먼저 .git이있는 디렉토리로 이동해주고

git pull muzzi-repo

수정된 github의 코드를 잘 받아온걸 확인 할 수 있다.

 

 

 

# 어떤 경우에 응용할 수 있을까?

나 혼자서 쓴다고 가정할떄, 내가 컴퓨터를 두대를 가지고 한 프로젝트를 진행하고 있다고 가정하자.

그림처럼 한 github레포지토리에 한 프로젝트 파일들을 넣어두고 두 컴퓨터에서 참조해서 관리한다고 해보자.

muzzi computer에서 코드를 업데이트 하고 레포지토리에 push를 했다.

근데 dori컴퓨터에서 로컬환경에선 muzzi컴퓨터에서만 코드를 수정해놨으니 로컬에서는 코드 수정사항을 반영이 안되어있다.

이때 pull을 하면, muzzi computer에서 수정한 코드내용이 dori computer에서도 적용이 되게 된다.

 

사실 난 컴퓨터 한대인 그지라서 애초에 pull을 쓸 이유도 없었는데, 예전에 컴퓨터 맛탱이가서 중고컴 새로 사서 쓸때 잠깐 만져봤던 기억이 남.. 

예시로 든 특수한 상황이 아니라면 사실 pull은 협업때 사용하는 명령어라고 생각한다.

 

 

 

 

# 만약 내 코드를 수정한 상태에서 pull을 하면? conflict!

저렇게 fix머시기 코드를 git-step1-posting디렉토리에서 추가하고 commit후 push했다.

근데 git step posting pull디렉토리에서 코드를 지멋대로 수정하고 commit을 때려버렸다.

 

이 상태에서 git step posting pull디렉토리에서 git step posting에서 수정하고 commit, push가 완료된 상태의 github코드를 git-step1-posting-pull디렉토리에서 pull해버린다면 어떻게 될까?

뭐가 되긴 됐는데?

어머 코드가 뭔가 드러워짐 ㅡㅡ

이게 바로 충돌이다.

같은 파일을 두 디렉토리에서 한번에 수정을 해버렸어서 충돌이 난거임.

이럴때는 원하는 코드를 골라주자

난 걍 둘다 맘에들어서 둘다 남겨줌

 

그리고 하던대로 해보자

git add .
git commit -m 'merge gogo'
git push muzzi-repo main

그래프가 이렇게 변했다. 뭔가 예뻐졌음.

충돌은 사실 혼자서 백업용도로 쓰려면 이런 특수한 상황 아닌경우에는 크게 안난다.. 정신만 제대로 차리면..

이 개념은 뒤에 협업, 브랜치 포스팅할때 자세히 추가할거고 이런게 있다 정도로만 알고 넘어가면 된다.

 

 

 

 

 

중요한 파일을 github에 안올리고싶을때? gitignore

 

파일을 두 개 만들어줬다.

no_secret.js파일과,

secret.js파일이다.

 

난 secret.js파일은 github에 안올라갔으면 좋겠음

 

이때 .gitignore파일을 만들어주자.

 

이렇게 secret.js파일을 .gitignore에 적어주자.

그리고 add commit 다시하고 push해보자

 

레포지토리에 no_secret.js파일은 올라갔는데, secret.js파일은 안올라갔다.

 

git ignore파일에서 설정한건 스테이징을 안해주는 파일을 지정해놓겠다임.

즉 secret.js를 깃으로 스테이징 안하겠다 하니 커밋자체에도 기록이 없고, 커밋된걸 github에 올려주는 push에서도 빠진거다.

.env같은 파일 관리할때 자주쓰는거다.

gitignore.io

그리고 자주쓰는 git ignore양식은 저런 사이트에 가면 본인 언어나 프레임워크 선택하면 알아서 잘 뽑아줌.

 

 

 

 

---

Conclusion

사실 위에적은 pull, reset등 명령어는 거의 쓰지도 않는다.
그냥 난 백업용도로만 써왔어서 필요가 거의 없었고 내가 아는 지식상에서만 코드를 관리하는게 오히려 실수나 큰 사건없이 코딩을 꾸준하게 해준것같음.
가끔은 하드코딩이라도, 무지로인한 사건사고를 막는점은 더 좋다고 생각한다. 
이번엔 취직하려고하다보니, 자세히 공부하고 적는것이지만 혼자 코딩하려는 사람들은 이 포스팅에서 딱 저것들만 알아도 무리없이 코딩할 수 있을것이다. 
암튼 깃이 처음 배우면 매우 짜증나고 뭐가뭔지모르겠지만 쓰다보면 매우 편하고 공짜 스토리지용로도 쓰기 좋으니까 익혀두는게 좋다.