Git 명령어 정리 (1) – 기초

작성자:

Git은 개발자들이 주로사용하는 프로젝트 버전관리 툴 입니다. 2026년 현시점에서 개발자나 소프트웨어 관련된 직종에서 일하고계신분은 모르시는분이 없겠죠? 그래서 이 글에서는 Git에대해 개념 설명을 하는것보다는 Git의 기초이자 필수 명령어를 정리하고 넘어가려고합니다. 저는 개인적으로 Git을 오래전부터 사용해왔지만, 제대로 알고 사용한지는 얼마 되지않습니다. 최근에 Git을 정식으로 배우게되어 Git에 대해 이해가 부족했던부분이 많이 명확해졌기때문에, 처음공부하시는분에게 도움이 될까하여 공유하고자 합니다.

Git 초기화

git 초기화는 두가지 방법이 있습니다.

  1. 로컬(내PC 혹은 주피터랩같은 가상공간) 에서 먼저 프로젝트 생성하는 방법.
  2. Github같은 사이트에서 먼저 온라인 리포지토리를 생성한 후 이를 복제(clone)하여 프로젝트 폴더를 생성하는 방법.

사실 정확히 설명을 드리면 2번은 가능한 방법일뿐 정석적인 방법은 1번입니다. Github이나 Gitlab같은 온라인 리포지토리는 사실 필수로 사용해야 하는건 아닙니다. 이들은 다음과 같은 목적으로 사용될 수 있습니다. 이 글에서는 백업기능을 사용할 수 있는 수준까지 알아보겠습니다.

  • 버전관리 *중급* – 버전관리는 왜 중급인가요? 맞습니다 버전관리는 Git을 사용하기만해도 자동으로 지원되지만, 여기서 버전관리등에서 문제가 생겼을때 해결하는방법은 조금 복잡할수 있습니다. 실제로 잘 사용하는사람이 Git사용자들중 25%도 되지않습니다.
  • 백업 (Github Projects) *기초*
  • 코드 or 프로젝트 공유 – 포트폴리오 제출 목적 or 프로젝트 협업 or 오픈소스 제공 (Github Projects) *기초*
  • Copilot 같은 AI활용한 개발 보조 *중급*
  • 보안 취약점 알림 (GitHub Security) – Github에서 API키를 발견한다거나 하는 보안취약점이 발견되면 사용자에게 알려줍니다. *중급*
  • 클라우드 개발공간 (GitHub Codespaces) – 주피터랩처럼 온라인상에서 코드를 작성및 실행해볼수있는 공간을 제공합니다. *중급*
  • CI/CD (GitHub Actions, Gitlab CI/CD) – *고급*
    CI (Continuous Integration) 지속적인 통합: 하나의 프로젝트가 여러개의 프로그램으로 이루어져있을때 이들을 통합하는것을 말합니다.
    CD(Continuous Deployment) 지속적인 배포: 통합된 프로젝트를 자동으로 배포해주는 기능을 말합니다.
    직접 프로젝트를 서비스 해보신분들은 내컴퓨터에서 개발하던것을 AWS등 실제 배포서버에서 작동시킬때 보안, IP, Port, 도메인, 권한설정 문제때문에 얼마나 많은 고려사항이 있는지 아실겁니다. 이것을 코드에 변화가 있을때마다 일일히 수동으로 설정해주면, 작은실수때문에 몇시간씩 시간낭비를 하게 될수도있고, 이때문에 아주 작은기능 하나를 수정하기위해서는 큰업데이트를 기다렸다 같이 배포하는 경우도있어서 서비스에 수정사항이 발생했을때 민첩한 대응이 어려워집니다. CI/CD는 이 복잡한 과정을 시간을들여 자동화를 해줍니다. 그러면 이후로는 사용자가 코드를 수정한후 git을통해 온라인 리포지토리 공간에 업데이트 해주면, 알아서 연결된 모든프로젝트를 통합하여 배포까지 자동으로 해줍니다. GitHub이나 GitLab을 사용했을때 얻는 장점중 가장 유익한 기능중 하나라고 보셔도 됩니다.

로컬에서 초기화

git init

이게 끝입니다. 터미널에서 본인이 사용할 프로젝트로 이동한 후 위 명령어를 사용하면 초기화가 완료됩니다. 이명령어를 사용하면 Git이 .git 이라는 숨은 폴더를 만드는데 이곳에 버전관리를 위한 정보를 저장할수있는 구조가 자동으로 생성됩니다.

다음 프로젝트를 어느정도 진행하시다가 어느 시점이되면 클라우드 공간에 백업을 해야겠다는 생각이 들면, GitHub에서 *빈* 리포지토리를 생성해줍니다. 그다음 해당 리포지토리의 주소를 아래처럼 remote 명령어를 사용하여 설정해줍니다.

git remote add origin https://github.com/(GitHub 사용자 이름)/(리포지토리 이름).git

이렇게하면 Git 초기화 및 Github 연동 까지 완료된것입니다.

Github에서 초기화

먼저 GitHub 웹사이트에서 리포지토리를 만든 후, 터미널에서 프로젝트 폴더를 *만들* 경로로 이동해줍니다. (프로젝트 폴더를 아직 만드시면 안돼요)

예를들어
~/work/workplace 가 프로젝트 경로라면
~/work 에서

git clone https://github.com/(GitHub 사용자 이름)/(리포지토리 이름).git

여기까지 해주시면 위에서 git init 와 git remote를 모두해준것과 같은 상태가 됩니다. 두 방법다 모두 사용가능한 방법이고, 위가 정석적인 방법이고 아래가 짧은방법이긴 하지만 어떤 방법을 써야한다는 정답은 없습니다. 중요 한것은 정확히 어떻게 작동하는지 이해하고 사용하는것이지요.

만약 처음 사용하신다면 위의 방법을 추천드립니다. 아직 로컬 컴퓨터가 GitHub와의 인증절차를 수행하지 않았기때문에, 비공개 프로젝트로 만드신경우 처음사용자는 clone이 바로 되지 않을겁니다.

Git 기본 사용법

위에서도 언급했듯, Git은 버전관리 도구로써, 사실 Github없이도 작동을 합니다. 버전관리의 중급기능은 다음 글에서 알아볼 예정이지만, 백업기능을 활용하기위해서 알아야할 기본기능이 존재합니다.

git add

가장먼저 내가 버전관리 할 파일을 Git에게 알려주는겁니다. 이걸 하지않으면 해당파일은 완전히 무시됩니다.

git add README.md

또는

git add .

git add . 은 새로추가된 모든 파일을 버전관리 및 백업하겠다고 알려주는 기능을합니다. 코딩을 하다보면 수많은 파일을 생성 및 추가를 하게되는데 이 때, 각각 파일을 일일히 add를 하면 비효율적일겁니다. 그래서 대다수의 사람들은 git add . 를 주로 사용합니다.

git commit

commit은 add명령어로 버전관리중인 모든파일들의 현재상태를 스냅샷으로 남겨두는겁니다. 예를들어 처음 프로젝트를 만들고 어떤 프로젝트인지 간단한 설명히 적힌 README.md 파일을 작성하셨다면, 아래와같은 commit 명령어를 수행할수있겠죠.

git commit -m "첫 README.md 파일 작성"

이 기능이 중요한 부분은, 백업을 할때도 commit으로 남긴 스냅샷 상태로 백업을 하게되고, 문제가 발생하여 이전상태로 복원을할때도 commit한 시점으로 복원할수있습니다. 예를들어 기능 A B C D 를 추가했는데, 내가 commit을 A기능 추가하고 나서 그리고 D 기능을 추가하고나서 했다면 B 나 C를 추가한 시점으로는 백업이 불가능합니다.

브랜치 (branch)

간단하게 push는 현재상태를 클라우드 리포지토리에 저장하는 기능이고, pull은 반대로 클라우드의 현재상태를 받아오는 기능입니다.

이를 사용하기 위해서는 브랜치(Branch)개념을 알아야 하는데, 나뭇가지를 뜻하는 branch단어를 사용해 갈래로 나눠졌다가, 다시 합쳐질수있는 기능을 표현한겁니다. 아래 사진처럼 프로젝트의 기둥이되는 Master 혹은 Main branch가 존재하고, 메인 프로젝트는 계속 개발하면서 동시에 버그수정을위해 빨간색 branch를 만들고 해결한다음 합치고 혹은 추가기능을 구현하는데 녹색 branch를 만들고나서 합치는 그런 기능이 존재합니다. 이 기능은 중급에서 알아볼것이고 지금은 push 명령어를 사용할때 branch이름을 언급해야하기에 짧게 설명 드렸습니다. 갈라지는 branch를 일단은 사용하지않고 메인 branch만 사용할것이기떄문에 아직은 빨간색이나 녹색은 신경쓰지말고 Master나 main 이름을 기억해주시면 됩니다.

브랜치 이름 바꾸기

master 를 main으로 바꾸기

# master 브랜치로 이동
git checkout master

# 현재 브랜치의 이름을 main으로 변경
git branch -m main
# 이름 한번에 바꾸기 (명령어 수행후 push까지 완료가 되야 클라우드까지 바뀜)
git branch -m master main

기본 브랜치 설정

우리는 한 프로젝트에 여러 브랜치가 존재한다는것을 알았고, 그렇다면 파일을 클라우드에 업로드할때 혹은 다운로드할때 브랜치 이름이 필요한것을 알수 있습니다. 근데 매번 이름을 지정하지않고 우리가 컴퓨터에서 기본 웹브라우저 설정하듯 기본 브랜치 설정하면 업로드(push), 다운로드(pull) 명령어만 사용해도 해당 브랜치에서 push, pull 하도록 설정이 가능합니다.

git branch --set-upstream-to=origin/main

main 브랜치를 기본브랜치로 설정한다는 명령어 입니다.

branch 브랜치 정보확인

#로컬 브랜치확인 - 현재 연결된 브랜치는 *로 표시
git branch

#원격 브랜치 확인 (r = remote)
git branch -r

#모든(로컬+원격) 브랜치 확인 (a = all)
git branch -a

#상세한 브랜치 확인 (v= verbose 상세한) - 현재 브랜치뿐만아니라, 커밋 해쉬 (롤백할때 필요), 커밋 메시지 까지 확인가능
git branch -v

log

롤백을 언급한김에, 롤백에 필요한 log 기능도 알아보죠.

#최근 3개 커밋 정보 확인
git log -3
#최근 2개 커밋 정보 확인
git log -2

#git log만쓰면 모든 커밋 = 낭비

#최근 5개 커밋을 요약해서 보기 (가장 흔히 쓰는 경우)
git log --oneline -5

#변경된 파일내용까지 보는 명령어
git log -p -2

#근데 위 명령어는 최근 두번 커밋동안 바뀐 모든파일을 다 보여줌. 

#마지막 커밋에서 특정 파일만 보는방법
git log -p -1 -- [파일명]
git log -p -1 -- README.md

#브랜치가 여러개일때  전체 브랜치 흐름 그래프로 시각적으로 보는방법
git log --oneline --graph --all -10

#리눅스에서 alias 사용해서 쇼트컷 만들기 이제 'git lg'만 치면 예쁜 그래프가 나옵니다.
git config --global alias.lg "log --oneline --graph --all"

#최근 커밋기준이 아닌 특정 파일기준으로 언제 바뀌었는지 보려면?  (추천)
git log --oneline -- [파일명]

#아래처럼 작성하면 README.md 파일이 바뀐 커밋이 언제였는지만 보여줌.
git log --oneline -- README.md

# 특정파일이 특정커밋시점에 바뀐내용 보기 (추천)
git show [커밋해시]:[파일명]  # 특정 시점의 파일 내용 보기
git show [커밋해시] -- [파일명] # 특정 시점의 파일 변경 사항(diff) 보기

#특정 파일 누가 수정했는지 보는 명령 (추천)
git blame [파일명]

git push & git pull

다시 본론으로 돌아와서, 이전 스텝의 commit 명령어까지 사용했다면 아래처럼 push 명령어를 사용해 클라우드공간에 프로젝트를 업로드할수 있습니다

git push origin master
또는
git push origin main

#만약 위에서 기본 브랜치를 설정했다면
git push

#반대로 서버상태를 다운받을경우
git pull

위 명령어를 pull 로바꾸면 클라우드에있는 상태를 받아오는 기능을합니다. 이떄 만약 내가 작업하고있는 코드가 클라우드에있는 버전보다 최신버전이면 (정확히말하면 클라우드에 있는 정보를 이미 다 받은상태에서 추가로 수정이 이루어진 상태라면) 다운받지않고 더 최신정보가 없다고 알려주고 끝납니다. 똑똑하죠?

반대로 push를하려고할때, 다른팀원이 수정을 한것이 존재한다면 충돌이 발생하여 어떤 것을 서버에 남기고 어떤것을 폐기할지 물어보는 경우도 있습니다. 이것역시 중급 글에서 다루겠습니다.

GitHub 인증하기 + 토큰 생성하기

GitHub 인증이란 로컬PC에서 작업한 프로젝트 파일을 push나 pull 할경우 (clone포함 비공개 프로젝트의경우) 사용자가 해당 리포지터리에 권한이 있는지 검증하는 과정입니다. 인증과정은 두가지 방법이있는데 하나는 push, pull 사용할때마다 github 아이디 비밀번호 입력하기 다른방법은 토큰을 로컬PC에 저장하여 이후로는 아이디 비밀번호를 입력하지 않아도 되는방법이 있습니다.

아이디 비밀번호 입력하기

토큰 생성하기

먼저 GitHub 웹사이트에 접속해서 회원가입을 마쳐주세요. 토큰을 만들려면 Github 저장소를 만들어야 하니까 저장소 만드는 방법도 간단히 알아볼게요.

Github 홈 화면에서 이곳 녹색 New 버튼을 눌러줍니다.

저장소 이름은 프로젝트의 GitHub 주소가 되므로 가능하면 영어로 만들어주세요.

설명은 작성할경우 저장소가 많아졌을때 구분하기 쉬워집니다.

Choose visibility는 프로젝트 공개여부인데 비공개로 만들경우 조건에따라 저장소가 자동으로 삭제되기도하니까 꼭 필요한경우가 아니면 공개로 해주세요.

나머지는 그대로 두고 녹색 Create repository를 눌러주면 저장소가 만들어집니다.

우측상단에있는 프로필 버튼을 눌러서 중간쯤있는 Settings를 눌러 설정 페이지를 열어줍니다. 그럼 세로로 긴 화면이 나오는데 스크롤을 내리면 사이드바 가장 아랫부분에 <> Developer settings라는 버튼이 보입니다. 이 버튼을 눌러주세요.

다음은 화살표 순서대로 눌러서 Generate New Tokwn (classic)을 눌러줍니다.

마지막으로 만료일을 설정하고 위의 3가지 체크박스를 선택후 Generate token버튼을 누르면 토큰이 생성됩니다.
체크박스는 이 토큰키를가지고있는사람이 사용할수있는 권한을 고르는것인데 이 3개면 기본기능을 사용할수 있다고 보시면됩니다.

생성하면 검은색 줄로 가려진부분에 토큰키가 나오는데 이를 복사해주면됩니다. 마지막으로 생성한 토큰을 컴퓨터에 저장해야하는데요. 2단계에 걸쳐서 저장할수있습니다. 먼저 git에게 내가 사용한 토큰을 저장하라는 명령을 내려줍니다. 아래처럼 사용하면되는데 토큰정보는 ~/ 루트경로에 .git-credentials 라는 파일에 저장되게 됩니다. 이를 다른경로에 저장하고싶으면 아래처럼 store 부분을 쌍따옴표로 감싸서 –file 키워드와함께 저장될 경로를 적어주시면 됩니다. 이 때 바로저장되지는 않고 아직 Git이 토큰을 알수없으므로 push나 pull 명령어를 사용하면서 토큰을 알려줘야합니다.

# 기본 저장 명령어
git config credential.helper store

# 경로를 바꿔서 저장할때 사용하는 명령어
git config credential.helper "store --file ~/work/.git-credentials"

push나 pull 명령어를 사용할때때 GitHub 아이디와 비밀번호를 물어보면, GitHub아이디를 그대로 적어주시고, 비밀번호를 물어볼때 토큰을 붙여넣기하고 엔터를 눌러줍니다. 이는 Git에게 토큰을 알려주는 것입니다. push나 pull이 성공적으로 완료되면 위의 파일이 저장되어 앞으로는 pull push등을 할때 아이디 비밀번호를 물어보지 않습니다.

댓글 남기기