Git) Eclipse에서 push로 GitHub에 공유하기

 

Git) Eclipse에서 Git 연결 후 커밋까지 진행해보기

[ GitHub에 Push 하기 ]

이전 포스팅에서 로컬 저장소에

커밋을 남기는 단계까지 끝냈다.

 

이번엔 그 커밋을 GitHub로 올려서

공유하는 과정을 정리한다.

 

이번 포스팅 목표

• 로컬 저장소에 원격 저장소 연결(origin) 만들기
• Eclipse(EGit) UI로 push 수행하기

---

용어 정리

origin
원격 저장소(remote)의 별칭.
GitHub repository URL을 로컬 저장소에 등록한 연결 이름이다.
push
로컬 커밋을 origin으로 업로드한다.
fetch
origin의 최신 커밋 정보를 로컬로 가져온다.
작업 폴더 파일이 바로 바뀌지는 않는다.
merge
가져온 origin/main을 내 main에 합쳐서 히스토리를 맞춘다.
pull
보통 fetch + merge를 한 번에 부르는 말이다.
Eclipse에서는 메뉴가 안 보일 때가 있어 fetch/merge로 대체한다.
origin/main
원격 main 브랜치를 로컬에서 추적하는 원격 추적 브랜치다.

---

1. GitHub repository URL 준비

GitHub repo 페이지에서

Code 버튼을 눌러 HTTPS 주소를 복사한다.

[그림 1] GitHub repo에서 Code → HTTPS 주소 복사 화면

---

2. Eclipse에서 origin(remote) 연결 만들기

로컬 커밋은 내 PC에만 존재한다.

GitHub로 공유하려면 로컬 저장소에

원격 저장소 주소를 등록해야 한다.

이때 등록되는 연결이 origin이다.

 

진행 위치

• Eclipse 뷰: Git Repositories
• 해당 저장소 하위: Remotes → origin

2-1) Push URL 등록

• Remotes → origin 생성 또는 Configure push
• Push URI에 GitHub HTTPS 주소를 등록

[그림 2] Eclipse Git Repositories에서 Remotes → origin 설정 진입 화면

[그림 3] Push URI 입력 창에 GitHub HTTPS 주소 붙여넣은 화면

2-2) Fetch URL도 등록(권장)
push만 해도 업로드는 되지만 협업/동기화를

설명하려면 fetch까지 등록해두는 게 깔끔하다.

fetch는 원격 변경을 가져오는 통로다.

[그림 4] origin에 fetch 설정(Configure fetch) 화면

---

3. Eclipse에서 push 실행

커밋이 준비되면 원격(origin)으로 업로드한다.

단 push는 커밋이 있어야 가능

커밋이 0개면 HEAD가 비어 있어 push가 실패한다.
즉, 최소 1번은 커밋을 만들고 난 다음 push 한다.

 

진행

• 프로젝트 우클릭 → Team → Push Branch…
• 또는 Git Staging에서 Push 관련 버튼 사용

확인할 것

• Source branch: main(또는 develop)
• Destination: origin의 main(또는 develop)
• Configure upstream for push and pull 체크 권장(다음부터 편해짐)
• Force overwrite는 체크하지 않는다(강제 덮어쓰기 위험)

[그림 5] Push 설정 화면(main → origin/main이 보이는 상태)

---

4. 인증: GitHub 비밀번호가 아니라 PAT(토큰)

HTTPS로 push할 때

GitHub는 계정 비밀번호가 아니라

PAT(토큰)을 요구하는 경우가 많다.

 

Eclipse 로그인창 입력 규칙

• User: GitHub 계정 아이디(예: teemo)
• Password: PAT 토큰 문자열
• 토큰을 만들 때 적는 토큰 이름은 라벨이라
  로그인 User에 쓰는 값이 아니다.

[그림 6] Eclipse 로그인창 화면

---

5. push 실패 케이스: rejected non-fast-forward

대표적으로 GitHub에서 README를

웹에서 먼저 만들면 원격 main에 커밋이 선행된다.

이 상태에서 로컬 main을 push하면

rejected non-fast-forward로 거절될 수 있다.

 

의미

• 원격 main이 로컬 main보다 앞서 있다.
• 원격 변경을 먼저 통합한 뒤 push하라는 신호다.

[그림 7] Push 결과에서 rejected non-fast-forward가 뜬 화면

---

6. 해결: fetch + merge로 원격 변경 통합 후 push 재시도

Eclipse에서 pull 메뉴가 안 보일 때가 있어서

fetch + merge로 해결하는 흐름이 안정적이다.

 

6-1) fetch 실행

• origin fetch 설정에서 Save and Fetch 실행
• 또는 Remotes → origin 우클릭 → Fetch from Upstream

[그림 8] fetch 실행 결과 화면(everything up to date 포함 가능)

 

6-2) merge 실행

• Branches → Remote Tracking
  → origin/main 우클릭 → Merge
• 작성자 정보(name/email) 창이 뜨면 입력 후 OK

[그림 9] Merge 완료 결과 화면

 

6-3) push 재시도
이제 로컬 main이 원격 main과 같은 히스토리를

포함하므로 push가 정상 동작한다.

[그림 10] push 성공 결과 화면(main → main, 전송된 커밋 목록 표시)

---

7. 업로드 완료 확인 방법

이클립스와 깃허브를 모두 확인한다.

 

7-1) Eclipse에서 확인

• History에서 origin/main 라벨이
  최신 커밋을 가리키면 원격 반영 완료다.

7-2) GitHub에서 확인

• repository → Commits에서
  방금 커밋 메시지가 보이면 업로드 완료다.

[그림 11] GitHub Commits 화면에서 커밋이 보이는 화면

---

※ 자주 나오는 문구: Resolving deltas

Resolving deltas는 전송된 변경분(diff)을 적용해

최종 상태로 정리하는 내부 처리 진행률 표시다.

→ 즉 오류가 아니라, 정상 진행 로그다.

---

[ 마무리 ]

• 로컬 커밋은 내 PC 안에서만 기록된다.
• origin(remote)을 연결하면
  GitHub로 push/fetch가 가능해진다.
• push는 공유의 시작이고 협업에서는 원격이 앞선 경우
  fetch/merge로 히스토리를 맞춘 뒤 push해야 한다.