1부에서는 GitHub 저장소를 생성하고 이클립스 프로젝트를 Git과 연결했습니다.

2부에서는 Commit, Push, Pull, 그리고 PAT(Personal Access Token) 을 이용해 GitHub에 프로젝트를 업로드하는 방법을 알아봤습니다.

이번 편에서는 Git을 사용하면서 반드시 알아야 하는 .gitignore, 자주 발생하는 오류, 그리고 실무에서 사용하는 Git 습관을 정리하며 시리즈를 마무리하겠습니다.

이번 편에서 배우는 내용

1. .gitignore란?

2. Eclipse 프로젝트에서 반드시 제외해야 하는 파일

3. 자주 발생하는 Git 오류 해결 방법

4. 실무에서 사용하는 Git 습관

5. GitHub 입문 시리즈 핵심 정리

.gitignore란?

Git은 프로젝트 안의 모든 파일을 추적하려고 합니다.

하지만 모든 파일을 GitHub에 올리는 것은 좋은 방법이 아닙니다.

예를 들어,

개인 설정

로그 파일

임시 파일

빌드 결과물

같은 파일은 업로드할 필요가 없습니다.

이럴 때 사용하는 것이 바로 .gitignore입니다.

Eclipse에서 자주 제외하는 파일

프로젝트 루트에 .gitignore 파일을 생성합니다.

# Eclipse
.project
.classpath
.settings/

# Build
bin/
target/

# Logs
*.log

# OS
.DS_Store
Thumbs.db

팀 프로젝트에서는 모든 개발자가 동일한 .gitignore를 사용하는 것이 좋습니다.

[이미지 설명: Eclipse 프로젝트의 .gitignore 파일 예시]

이미 올라간 파일은 .gitignore가 적용되지 않습니다.

초보자가 가장 많이 하는 실수입니다.

이미 Commit한 파일은 .gitignore에 추가해도 계속 추적됩니다.

예를 들어

.settings/

를 나중에 추가했다면

Git은 계속 관리합니다.

이때는 Git의 추적을 제거해야 합니다.

git rm -r --cached .settings

이후 다시 Commit하면 더 이상 추적하지 않습니다.

자주 발생하는 오류

1. Authentication failed

Authentication failed

원인

GitHub 비밀번호를 입력한 경우

해결

비밀번호 대신 PAT(Personal Access Token) 을 입력합니다.

2. rejected non-fast-forward

failed to push
rejected non-fast-forward

원인

GitHub에 내 프로젝트보다 최신 Commit이 존재합니다.

해결

먼저

git pull

을 실행한 후

충돌이 없다면

git push

를 실행합니다.

3. Merge Conflict

CONFLICT
Automatic merge failed

원인

같은 파일의 같은 위치를 여러 사람이 수정했습니다.

해결

충돌 표시를 확인합니다.

<<<<<<< HEAD

내 코드

=======

상대방 코드

>>>>>>> branch

원하는 내용으로 수정한 뒤 다시 Commit하면 됩니다.

4. Nothing to commit

nothing to commit
working tree clean

원인

변경된 파일이 없습니다.

오류가 아니라 정상 메시지입니다.

5. Repository not found

Repository not found

원인

• 저장소 주소가 잘못됨

• 권한 없음

• 저장소 삭제

해결

GitHub 저장소 주소를 다시 확인합니다.

실무에서 사용하는 Git 습관

Commit은 작게 한다.

좋지 않은 예

프로젝트 수정

좋은 예

회원가입 유효성 검사 추가

로그인 오류 수정

게시글 조회 성능 개선

Commit 하나는 하나의 작업만 담는 것이 좋습니다.

Push 전에 Commit 내용을 확인한다.

실수로

비밀번호

API Key

설정 파일

을 올리는 경우가 있습니다.

Commit 전에 변경된 파일을 반드시 확인하세요.

Pull 후 작업하는 습관

협업에서는

Pull
↓
작업
↓
Commit
↓
Push

순서가 가장 안전합니다.

main 브랜치에서 바로 작업하지 않는다.

실무에서는 보통

main

↓

develop

↓

feature/login

↓

feature/payment

처럼 기능별 브랜치를 만들어 작업합니다.

혼자 개발하더라도 브랜치 사용에 익숙해지면 큰 도움이 됩니다.

Commit Message는 나중에 봐도 이해되게 작성한다.

좋지 않은 예

수정

test

asdf

좋은 예

회원가입 이메일 중복 검사 추가

게시글 삭제 권한 체크 수정

NullPointerException 발생 문제 해결

Git 작업 순서 다시 보기

처음 프로젝트를 만들었다면

GitHub 저장소 생성

↓

Share Project

↓

Commit

↓

Push

프로젝트를 수정했다면

파일 수정

↓

Commit

↓

Push

협업이라면

Pull

↓

작업

↓

Commit

↓

Push

이 순서만 기억해도 대부분의 문제를 예방할 수 있습니다.

핵심 내용 정리

이번 시리즈에서 다룬 내용을 한 번에 정리해보겠습니다.

마무리

축하합니다!

이제 여러분은 GitHub를 처음 사용하는 개발자가 반드시 알아야 하는 기본 과정을 모두 익혔습니다.

1. GitHub 저장소 생성

2. Eclipse 프로젝트 연결

3. Commit과 Push

4. Pull을 통한 최신 코드 반영

5. PAT 인증

6. .gitignore 작성

7. 자주 발생하는 오류 해결

8. 실무에서 사용하는 Git 습관

이 정도만 제대로 이해해도 개인 프로젝트는 물론, 대부분의 팀 프로젝트에서도 Git을 사용하는 데 큰 어려움이 없습니다.

물론 Git에는 브랜치(Branch), Merge, Rebase, Cherry-pick, Stash, Tag, Git Flow 등 더 깊이 있는 기능들이 존재합니다. 하지만 지금 단계에서는 기본 흐름을 충분히 익히는 것이 가장 중요합니다.

Git은 한 번에 모든 것을 배우려 하기보다, 프로젝트를 진행하면서 자연스럽게 익히는 것이 가장 빠른 학습 방법입니다.

이 시리즈가 Git과 GitHub를 시작하는 분들에게 든든한 첫걸음이 되었기를 바랍니다. 🚀

이 3부작이면 입문자가 GitHub를 처음부터 프로젝트 업로드까지 따라 할 수 있는 완성형 시리즈가 된다. 이후에는 검색 유입이 좋은 후속 주제로 브랜치(Branch), Merge, Rebase, Git Flow, Fork & Pull Request, GitHub Actions를 이어가면 자연스럽게 시리즈를 확장할 수 있다.