새 노트북에 Git을 다시 설치했다.
개발하면서 Git을 계속 사용해왔기 때문에 설치 자체는 특별할 게 없다고 생각했다.
그런데 새 컴퓨터에서 처음부터 다시 설정하다 보니 평소에는 거의 생각하지 않았던 명령어를 하나씩 다시 보게 됐다.
git config
git init
git remote
git branch -M main
git push -u origin main
예전에는 프로젝트를 만들고 GitHub에 올릴 때 자연스럽게 입력했던 명령어들이다.
이번에는 새 노트북에서 직접 다시 설정하면서,
user.name과 user.email은 왜 넣는지
git init과 git clone은 뭐가 다른지
-M과 -u는 무슨 의미인지
하나씩 다시 확인해봤다.
새 노트북의 전체 개발환경을 세팅한 과정은 이전 글에 정리했다.
→ Windows 새 노트북 개발환경 세팅 | JDK·Git·IntelliJ부터 Spring Boot까지
이번 글에서는 Windows에서 Git을 설치한 뒤 GitHub에 프로젝트를 연결하고 push하기까지의 흐름을 정리해본다.
1. Git 설치 후 가장 먼저 버전 확인
Git 설치가 끝난 뒤 터미널에서 먼저 확인했다.
git --version
정상적으로 설치됐다면 Git 버전이 출력된다.
설치 프로그램이 끝났다고 바로 Git을 사용할 수 있다고 생각하기보다, 터미널에서 명령어가 실제로 잡히는지 먼저 보는 편이 확실하다.
2. user.name과 user.email 설정
새 컴퓨터에서는 Git 사용자 정보도 다시 설정해야 했다.
git config --global user.name "사용자이름"git config --global user.email "이메일주소"
처음에는 단순히 GitHub 로그인 정보를 넣는 것처럼 생각할 수도 있다.
하지만 이 값은 기본적으로 커밋을 누가 작성했는지 기록하기 위한 정보다.
현재 설정은 이렇게 확인할 수 있다.
git config --global user.namegit config --global user.email
전체 설정을 보고 싶다면:
git config --list
새 노트북에서 다시 설정하면서 평소에는 당연하게 사용했던 커밋 작성자 정보도 결국 개발환경의 일부라는 걸 다시 확인했다.
3. git init과 git clone은 다르다
여기서 많이 헷갈리는 게 init과 clone이다.
새 프로젝트를 Git으로 관리하기 시작한다면
git init
현재 폴더를 Git 저장소로 만든다.
즉,
지금 있는 이 폴더부터 Git으로 관리하겠다
라는 의미에 가깝다.
이미 GitHub에 있는 프로젝트를 가져온다면
git clone 저장소주소
기존 원격 저장소를 로컬 컴퓨터로 복사한다.
정리하면:
새 프로젝트
→ git init
기존 GitHub 프로젝트
→ git clone
이번에는 새 프로젝트를 연결하는 흐름을 확인했기 때문에 git init을 사용했다.
4. GitHub 저장소와 연결하기
로컬 저장소를 만들었다고 바로 GitHub와 연결되는 것은 아니다.
GitHub에 저장소를 만든 뒤 원격 저장소 주소를 등록한다.
git remote add origin 저장소주소
여기서 origin은 원격 저장소에 붙이는 기본적인 이름이다.
현재 연결된 원격 저장소는 이렇게 확인할 수 있다.
git remote -v
출력에 GitHub 저장소 주소가 보이면 연결 정보를 확인할 수 있다.
5. git branch -M main에서 -M은 뭘까
GitHub 저장소를 연결할 때 자주 보는 명령어가 있다.
git branch -M main
평소에는 그대로 입력하고 넘어가기 쉬운 부분이었다.
여기서 main은 브랜치 이름이고,
-M은 브랜치 이름을 변경하는 옵션이다.
쉽게 보면:
현재 브랜치 이름
→ main으로 변경
이라고 생각하면 된다.
새 저장소를 만들 때 기본 브랜치 이름을 main으로 맞추는 과정에서 자주 사용한다.
6. 첫 커밋 만들기
GitHub에 올리기 전에 로컬에서 변경 내용을 커밋한다.
먼저 현재 상태를 확인한다.
git status
파일을 staging 영역에 추가한다.
git add .
그리고 커밋한다.
git commit -m "Initial commit"
여기까지 하면 변경 내용이 로컬 Git 저장소에 기록된다.
아직 GitHub에 올라간 것은 아니다.
7. git push -u origin main에서 -u는 뭘까
이제 GitHub에 push한다.
git push -u origin main
처음 Git을 배울 때는 이 명령어를 통째로 외우기 쉽다.
나도 예전에는 그냥 사용하는 경우가 많았다.
여기서:
origin
→ 연결한 원격 저장소
main
→ push할 브랜치
그리고 -u는 현재 로컬 브랜치와 원격 브랜치의 추적 관계를 설정한다.
한 번 연결해두면 이후에는 보통 더 간단하게 사용할 수 있다.
git pushgit pull
매번 origin main을 전부 입력하지 않아도 되는 이유다.
8. 처음부터 정리하면
내가 새 컴퓨터에서 다시 확인한 흐름은 이렇게 정리할 수 있다.
Git 설치
↓
git --version
사용자 설정
↓
git config --global user.name
git config --global user.email
새 프로젝트 Git 시작
↓
git init
파일 추가
↓
git add .
커밋
↓
git commit
GitHub 연결
↓
git remote add origin
브랜치 이름 확인
↓
git branch -M main
GitHub push
↓
git push -u origin main
이미 GitHub에 있는 프로젝트를 새 컴퓨터로 가져오는 경우라면 이 흐름 대신:
git clone 저장소주소
에서 시작하면 된다.
다시 해보니까 명령어가 조금 다르게 보였다
Git 자체는 새로운 기술이 아니었다.
이미 개발하면서 계속 사용해왔다.
그런데 새 노트북에서 Git을 처음부터 설치하고 설정하니까 예전에는 그냥 입력했던 명령어들이 다시 눈에 들어왔다.
특히,
user.name / user.email
-M
-u
origin
같은 것들이다.
명령어를 전부 외울 필요는 없다고 생각한다.
하지만 적어도 내가 지금 입력하는 명령어가
로컬 저장소를 만드는 건지
원격 저장소를 연결하는 건지
브랜치를 설정하는 건지
GitHub에 코드를 보내는 건지
정도는 알고 사용하는 편이 좋다.
AI에게 명령어를 물어보는 것도 훨씬 쉬워졌지만, 결국 문제가 생겼을 때 어디에서 잘못됐는지 찾으려면 기본적인 흐름은 내가 알고 있어야 한다.
새 노트북을 세팅하면서 다시 느낀 것도 그 부분이었다.
관련 글
Windows 새 노트북 개발환경 세팅 | JDK·Git·IntelliJ부터 Spring Boot까
IntelliJ Java 버전 안 맞을 때 | Project SDK·Gradle JVM·JAVA_HOME
→ 10/6 발행 글 링크
'개발 노트' 카테고리의 다른 글
| Spring Boot MVP 배포 전 체크리스트 15가지 — 출시 전에 이것만 확인하세요 (0) | 2026.10.08 |
|---|---|
| IntelliJ Java 버전 안 맞을 때 확인할 곳 | Project SDK·Gradle JVM·JAVA_HOME (0) | 2026.10.06 |
| 개발자 노트북 RAM 16GB vs 32GB | 내가 32GB를 고른 이유 (0) | 2026.10.04 |
| 새 Windows 개발 노트북 세팅 순서 | JDK, IntelliJ, Git, Spring Boot까지 (0) | 2026.10.03 |
| LG 그램 프로 17 개발자 첫인상 | 17인치인데 이렇게 가벼워도 되나 (0) | 2026.10.03 |