Git, GitHub 제대로 알고 쓰기
팀 프로젝트를 진행하면서 카카오톡. 이메일 등으로 파일을 주고받다가 서로 다른 버전으로 덮어써본 적이 다들 한 번쯤 있을 것이다. 이런 일이 일어나지 않도록 Git과 GitHub를 사용하는 것이 좋다.
Git과 GitHub를 같은 것으로 아는 사람들이 은근 많은데, 둘의 역할은 완전히 다르다. Git은 내 컴퓨터 안에서 파일 변경 이력을 관리해주는 프로그램이고, GitHub는 그 Git 저장소를 온라인에 업로드하여 남들과 공유할 수 있도록 해주는 서비스이다. Git만 쓰면 혼자 버전 관리하는 정도지만, 팀원들과 코드를 주고받으려면 GitHub같은 원격 저장소가 필요하다.
Window에서 설치 및 초기 설정하기
git-scm.com에서 설치하거나, winget이 깔려 있다면 명령어를 통해 설치할 수 있다.
powershell
winget install --id Git.Git -e --source winget
설치 과정에서 뭘 선택해야 할지 애매한 옵션이 몇 개 있는데, 기본값 그대로 눌러도 무방하다.
다만 "Adjusting your PATH environment" 단계에서는 세 번째 옵션인 Git from the command line and also from 3rd-party software를 선택해주면 나중에 편하게 사용이 가능하다. 설치 과정이 끝나면 Git Bash가 생기는데, 앞으로 Git 명령어를 이 터미널에서 치면 된다.
설치가 끝나면 Git Bash를 켜서 기본 브랜치 이름부터 맞추면 된다.
bash
git config --global init.defaultBranch main
예전에는 master가 기본값이었지만 요즘은 다들 main을 쓴다.
커밋을 남기려면 누가 작업했는지 정보가 있어야 한다. 아래 명령어로 등록을 해준다.
bash
- 등록
git config --global [user.email]
git config --global [user.name]
- 삭제
git config --global --unset-all user.email
git config --global --unset-all user.name
--global을 붙이면 컴퓨터 전체에 적용되고, 빼면 지금 있는 저장소에만 적용된다.
Git을 이해하려면 구조부터 알아야한다.
Working Directory --(git add) --> Staging Area --(git commit) --> Repository
현재 내가 수정하는 실제 파일등이 Working Directory에 있고, 커밋에 넣고 싶은 변경사항을 모아둔 곳이 Staging Area이다. 여기서 커밋을 하면 그제야 Repository에 하나의 버전으로 기록된다.
수정만 한다고 바로 기록되지 않는다. 일단 add로 Staging에 올려야 그 다음에 커밋을 할 수 있다.
Pro Git 북 사이트에 자세하게 기록되어있다.
Git 명령어
bash
git init
- 현재 위치를 Git 저장소로 만드는 명령어
bash
git add [파일명]
git add .
- 수정한 파일을 staging Area에 올리는 명령어
- . : 현재 폴더 전체
- ../ : 상위 폴더
- / : 최상위 폴더
bash
git commit -m [메시지]
git commit --amend -m [새로운 커밋 메시지]
- Staging에 올라간 내용을 하나의 버전으로 확정하는 명령어
- 마지막에 commit한 메시지를 변경하는 명령어
[메시지]에는 무엇을 바꿨는지 짧게 적어두면 좋다.
- feat: 새로운 기능 추가
- fix: 버그 수정
- docs: 문서 수정 (README 등)
- style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
- refactor: 코드 리팩토링 (기능 변경 없이 코드 구조 개선)
- test: 테스트 코드 추가 및 수정
- chore: 빌드 프로세스, 패키지 매니저 수정 등 자잘한 작업
bash
git status
- 어떤 파일이 바뀌었는지 or Staging에 올라가 있는지 아닌지 확인하는 명령어
bash
git log
- 커밋 이유 기록을 확인 할 수 있는 명령어
commit 9d684a026cd2e6606ca6747c3c59a82ffcc1c2b8 (HEAD -> main)
- 형상을 관리하기 위한 고유한 식별자(id)
Author: Bucheo atfqwe80@gmail.com
- 작성자 이름 <작성자 깃허브 이메일>
Date: Fri Sep 11 09:42:05 2026 +0900
- 작성 일자
bash
git reset --hard
git reset --hard [commit id]
git reset --hard [브랜치명]
- 현재 작업물을 모두 초기화시키고 이전 버전으로 되돌리는 명령어
- 현재 브랜치를 이전 버전으로 적용시키는 명령어
브랜치를 나눠야 하는 이유
팀 프로젝트에서 가장 흔하게 발생하고 사고는 main에서 작업하는 것이다. 그러면 누가 뭘 고쳤는지 확인하기 힘들고 충돌이 잦아진다. 이 때문에 브랜치를 만들어서 작업을 한다.
main에서 절대 작업하지 않고, 기능 단위로 브랜치를 만들어 작업을 진행한다. 끝나면 main으로 합친다. 최종 브랜치는 main이다.
브랜치 명령어
bash
git checkout -b [브랜치명]
- 브랜치를 생성함과 동시에 만들어진 브랜치로 이동
bash
git branch [브랜치명]
- 브랜치를 생성하는 명령어
bash
git branch
- 만들어진 브랜치와 현재 나의 브랜치를 확인하는 명령어
bash
git branch -m [기존 브랜치][수정할 브랜치]
- 브랜치의 이름을 수정하는 명령어
레포지토리 명령어
bash
git remote add [레포지토리명][GitHub 주소]
- GitHub 주소를 레포지토리명 주소에 담는 명령어
origin: 개인 레포지토리project: 팀 레포지토리
bash
git remote remove [레포지토리명]
- 저장된 remote의 레포지토리를 삭제하는 명령어
bash
git push origin main
- origin으로 main 브랜치를 push하는 명령어
bash
git pull origin main
- origin으로 main 브랜치를 pull하는 명령어
bash
git clone [레포지포리 주소]
- 파일 전체를 가지고오는 명령어
