[ Git ] git bash 주요 명령어 정리

shell 기초 명령어

• pwd : (print working directory) 현재 위치 확인
• ls : 현 위치에 있는 파일들 확인
• clear : 쉘 청소(앞서 입력한 내용지우기)
• mkdir : 현 위치에 새로운 폴더 만들기
  • mkdir hello : 현 위치에 hello라는 새로운 폴더 생성
• touch a.txt : 현 위치에 a.txt라는 텍스트 파일 생성
• echo : 문자열 출력
  • echo "hello" > a.txt : a.txt파일에 hello라는 문자열 삽입
• cat : 확인용 명령어
  • cat a.txt : hello 출력됨
• cd : 특정 위치로 이동
  • cd hello/ : hello 라는 폴더로 이동
  • cd .. : 상위 폴더로 이동
• cp : 파일 복사
  • cp a.txt hello/ : hello라는 폴더로 a.txt가 복사됨

 

git 관련 명령어

컴퓨터에 처음 git을 다운받아 사용하려할때

내 컴퓨터와 내 git계정을 연동시키는 작업. 만약 본인 소유의 컴퓨터가 아닌 공용 컴퓨터라면 쓰지 않는게 좋음.

• git config --global user.email "내이메일"
• git config --global user.name "내계정이름" (global : 컴퓨터 전체에서 사용하겠다는 의미)
• 혹시 비밀번호를 입력하는 과정에서 화면에 입력한 비밀번호가 보이지 않을 수 있는데 우리 눈에만 안보일 뿐 비밀번호는 입력되고 있는 중이니 오타 없이 잘 입력해주면 된다
• git config --global -l  (영문 소문자 엘이다) : 현재 컴퓨터에 연동된 계정을 확인하는 명령어

 

내 로컬 폴더와 git repository를 연결하는 작업

remote repo, 즉 github이나 gitlab과 같은 원격 저장소에 있는 repository와 내 로컬 폴더(내 컴퓨터 내부에 있는 폴더)와 연결시키는 작업을 하는 명령어

• git remote add origin 링크
  • 링크 자리에는 repository의 url을 복사해서 넣으면 됨
  • control + c 를 써서 붙여넣으려고 할 때 에러가 날 수 있으니(원래 종료할 때 쓰는 명령어이기도 해서) shift+insert 키를 써서 복사한 내용을 삽입하는것이 좋다
• git remote -v : 현재 이 폴더가 어떤 원격저장소와 연결되어있는지 확인하는 명령어

그런데 만약 내가 연결시켜야 하는 저장소가 아니라면 해당 폴더의 remote repo정보를 지워줘야 함

• git remote rm origin ( 참고로 origin은 default처럼 사용하는 이름이고 따로 설정할 수도 있긴 하다 )
  • rm은 remove의 의미

 

만약 어떤 git repository의 내용을 로컬 폴더로 끌어오고싶다면?

복제인간을 만들때 클론 만든다고 하듯이, 여기서도 원격 저장소의 클론을 내 컴퓨터에 만들겠다는 명령어를 사용

• git clone 원격저장소url
  • 위 명령어를 쓰면 내 현재 폴더 위치에 원격저장소의 내용이 하나의 폴더가 되어 새로 생성된다. 하지만 다시 그 폴더 안으로 들어가야 내가 원하는 내용들을 확인할 수 있다는 불편함이 있다. 그냥 내 현재 폴더에 바로 그 내용들을 끌어오고 싶다면?
  • git clone 원격저장소url .
    • 이렇게 맨 뒤에 띄어쓰기 한번 하고 .을 찍어주면 원격저장소의 내용들이 내 현재 폴더에 모두 들어온다(따로 폴더 하나가 생성되는게 아니라 바로 내용이 현재 위치로 들어오는 편리한 코드)

 

원격 저장소에 내용이 새롭게 업데이트 되었는데, 내 로컬 폴더에도 이를 반영하고싶다면?

이미 clone을 받은 상태라는 가정 하에 다음 명령어를 입력하면 됨

• git pull origin 브랜치이름
  • 브랜치 이름은 얼마 전까지는 보통 master가 dafult였는데 main으로 바뀌었다(github의 경우)
  • 핵심은 내가 끌어오고픈 내용이 담겨있는 브랜치의 이름을 입력해주면 됨

하지만, 여기서 다음과 같은 상황일 때는 에러가 발생한다

• 내가 처음 원격 저장소 내용을 로컬에 clone 받은 뒤에 로컬 환경에서 해당 내용을 수정하거나 변경시키는 작업을 하고 상태 관리(git add나 git commit 등의 작업)을 한 상황에 만약 원격 저장소에 업데이트 된 내용과 내가 수정한 부분에 겹치는 부분이 있을때
  • git 내부적으로 혼란이 생긴다. 원래 git은 똑똑해서 만약 적당히 덮어쓸 수 있을 경우 덮어쓰려하는데 만약 같은 코드를 건드리거나 하면 무엇을 남기고 무엇을 지워야 할지 몰라 에러를 내는 것이다

이런 상황에는 다양한 해결책이 있는데, 

1. 내가 수정한 작업, 상태 관리했던 내역을 지우고 원래 상태로 돌아간 뒤 git pull을 다시 하는 것
2. 브랜치를 하나 새로 파서 내가 작업하던 내용을 담아놓고, 기존 브랜치 커밋내역을 돌려서 다시 git pull 받는 것
3. 새로 clone 받는 것

개인적으로는 용량이 매우 크다거나 어쩔 수 없는 사정이 있지만 않으면 새로 clone받는게 제일 마음이 편하다. 새로 클론 받은 뒤에 거기에 내가 수정한 내용을 덧입힌 뒤 상태관리를 하고 이전에 클론받았던 폴더는 지워버리는게 그나마 쉽고 깔끔한 방법.

 

아직 원격저장소를 만들지는 않았지만, 로컬에서 새로 프로젝트를 시작하려 한다면?

연결시킬 수 없는 git repo가 아직 없지만, 로컬에서 충분히 상태 관리를 할 수 있다. 먼저 상태 관리를 하겠다고 선언을 해주고 시작하면 된다.

• git init : 이 폴더를 git으로 상태관리하겠다
  • 이때 숨긴 파일 보기를 클릭하면 아마 불투명하게 .git 폴더가 생기는데 바로 이 폴더에 변경내역들이 저장되는 것이다. 혹시라도 이 폴더를 삭제하면 상태관리 내역이 사라진다고 보면 된다. 만약 git으로 더이상 관리할 생각이 없다면 삭제하면 된다. 삭제한 이후 git bash를 열어보면 활성화된 브랜치이름이 뜨지 않는다. (왜냐면 git으로 변경사항을 추적하고 있지 않게 되었기때문에)

 

상태관리

제일 중요한 상태관리. 일단 상태를 관리한다는 건 최종본, 진짜 최종, 이게 진짜진짜최종, 완전 최종 이런 복사본을 매번 만들지 않고, 이전 파일에서 달라진 내역만 커밋으로 저장해서 변경 내용의 이력을 계속 관리하겠다는 것이다. 물론 내부적으로 git이 어떻게 작동하는지 인강을 들어보면 더 이해가 잘 되는데 사실 적당히 사용법만 익히면 잘 쓸 수 있어서 굳이 인강을 들을 필요까지는 없는것같기도하다. (하지만 인프런 git 원리 강의는 꽤 재밌게 봤음 )

git 원리까지 들어가면, 어떤 명령어는 어떤 공간에 변경내용을 올리는 것이고 어떤 명령어는 이걸 실행하겠다는 의미고 어떤 명령어는 이걸 원격 저장소에 반영하겠다는 의미라는 식으로 아주 상세히 설명할수도 있지만, 내가 프로젝트 할 때 그냥 항상 기억하고 쓰는 명령어는 아래 명령어들이다.

• git log : 지금까지의 커밋 이력을 확인하고 싶을때 (버전 기록)
• git status : 마지막 버전와 지금 현재 상태와의 차이를 보여줌(변경 내역이 있는지, add를 하지 않으면 확인 못함)
• git add : 지금까지 변경한 내용을 다음 버전(커밋)에 반영하겠다
  • git add a.txt : a.txt에 내가 수정한 것을 다음 버전(커밋)에 반영하겠다
• git commit : 지금까지 add했던 내용을 하나의 버전으로 묶겠다
  • git commit -m "안에 커밋 메시지를 적어주면 됨"
  • ex) git commit -m "210618 | UPDATED | readme 내용을 수정함"

여기서 add, commit을 아주 단순화해서 비유하자면 이렇다. (정확한 비유는 아니다! 하지만 대충 느낌은 이런 느낌)
- add : 내가 문서 작업을 할 때 계속 ctrl+s 누르면서 저장하는 작업 (= 하나의 버전을 만들기까지의 수정내용)
- commit : 그 저장한 파일을 "다른이름으로 저장"하는 작업 (= 하나의 버전이 되어 기록으로 남는 것)

일단 여기까지 하면 하나의 버전이 만들어진것인데, 원격 저장소에 들어가보면 이 내용이 반영이 안되어있다. 그 이유는 원격 저장소로 이제 올리겠다! 라는 명령어를 치지 않았기 때문이다. 이 명령어는 아래와 같다

• git push origin 브랜치명
  • ex) git push origin main

 

사실 여기까지는 아주 기초적인 부분이고, 여기까지만 잘 이해해도 git으로 개인 작업을 하는데는 무리가 없다. 하지만 팀으로 작업할 때에는 git commit rule이나 규칙이 없으면 엄청난 에러를 보게 될수도 있다. 그래서 협업을 할 때에는 브랜치의 개념, merge의 개념을 알고 git으로 작업해야 쓸데없이 에러를 해결하는 데 고생하지 않는다. 또 협업할 때만큼은 항상 습관적으로 pull 땡긴 뒤에 바로 브랜치를 하나 딴 다음 내 작업 한 뒤 룰에 맞춰 commit, push하고 merge요청 보내는 이런 루틴을 만드는게 좋은데 협업할때의 git이나 git의 원리에 대해서는 다음 포스트에...