9월 22, 2025

GitHub 협업 – 이클립스로 깃허브 저장소 연결하기 (팀장버전)

깃허브 이클립스 저장소 연결방법 (팀장 버전)

📌 날짜: 2025년 9월 22일
📌 도구: Eclipse, Github

1. 팀장이 해야 할 첫 작업

우리 팀의 프로젝트를 깃허브에 올리기 위해 제일 먼저 팀장이 자신의 깃허브 계정에 레포지터리를 생성해야 한다.
그 다음 이클립스를 실행해서 레포지터리와 동일한 이름으로 프로젝트를 만들어야 한다.
(이름이 같아야 커밋 과정에서 문제가 없다!)

2. 로컬 저장소 세팅

이클립스에서 프로젝트를 만든 뒤, 오른쪽 클릭 → Team 메뉴에서 깃 관련 설정을 들어간다.
여기서 .git 숨김 파일이 생성되는데, 이게 곧 깃 저장소 설정 파일이다.
이제 이클립스 왼쪽에 물음표 아이콘(??) 이 뜨는데, 이건 아직 원격 저장소에 올라가지 않은 파일을 의미한다.

3. 브랜치와 저장 구조 이해하기

main 브랜치는 완성본을 올리는 공간이다.
실제 개발은 새로운 브랜치를 따서 진행한 뒤, 최종적으로 main에 병합한다.
이클립스는 옛날 방식이라 아직 master 브랜치라고 표시되는 경우가 있다.

3-클론 깃레포지토리로 원격 레포지토리와

내 컴퓨터 연결하기

4. Git Staging과 Git Repository / Commit

이클립스에서 Git Staging 창을 열면 파일들이 Unstaged 상태로 보인다.
여기서 add를 통해 Staged 영역으로 옮겨야 한다.

Unstaged → Staged = add (클럽 보디가드가 입장 허가하는 것과 같다)
Staged → Local Repo = commit (내 로컬 저장소에 저장하는 것)

커밋이 완료되면 staging 창이 깨끗하게 비워진다.

5. Remote 연결하기

원격 저장소(GitHub)와 연결해야 push가 가능하다.
깃허브는 이제 비밀번호 대신 토큰 방식으로 연결한다.

Github → Settings → Developer Settings → Personal Access Token 발급
토큰은 티켓처럼 한 번만 발급되며, 재발급하면 기존 토큰은 다 끊어진다.
발급 시 Note(이름), 유효기간, 권한(repo, admin)을 체크한다.
admin:repo_hook체크한다.
토큰을 복사해서 잘 보관한다.

그 다음 이클립스에서 Remote → Create Remote를 선택 후,

origin = 내 원격 저장소
upstream = 팀장의 원격 저장소

으로 각각 이름짓고 연결한다.

팀장은 upstream 만 있으면 되나?

팀장의 역할에 따라 필요 여부가 달라질 수 있지만, 일반적으로 팀장도 origin과 upstream을 모두 설정하는 것이 효율적입니다.

팀장에게 origin과 upstream이 모두 필요한 이유

팀원들의 포크(fork)된 저장소와 협업할 경우: 팀원들이 메인 저장소를 포크해서 작업하고 풀 리퀘스트(PR)를 보내는 워크플로우라면, 팀장은 팀원들의 포크된 저장소(팀원들의 origin)에 접근할 필요가 있습니다. 이렇게 하면 팀원들이 보낸 PR을 확인하거나, 필요에 따라 직접 팀원들의 브랜치를 로컬로 가져와 검토할 수 있습니다.
메인 저장소 유지보수: 팀장은 메인 저장소(upstream)에 대한 모든 권한을 가지고 있습니다. 하지만, 다른 저장소에서 변경 사항을 가져오거나 동기화해야 할 경우 upstream이라는 이름으로 설정해두면 팀원들과 같은 방식으로 작업할 수 있어 편리합니다.

상황별 필요한 원격 저장소

상황	필요한 원격 저장소	이유
팀장이 메인 저장소에서만 작업	`origin`만 있어도 충분	메인 저장소(`origin`)에 바로 푸시(push)하고 풀(pull)하기 때문에 다른 원격 저장소는 필요하지 않습니다.
팀원이 포크한 저장소와 협업	`origin`과 `upstream` 모두 필요	`upstream`은 메인 저장소를, `origin`은 다른 팀원의 저장소를 가리키는 방식으로 협업할 때 유용합니다.

6. Push 전에 꼭 알아야 할 것

push가 안 되는 가장 큰 이유는 로컬과 원격이 동기화되지 않았기 때문이다.

원격에 이미 뭔가 있다면 push 불가 → 먼저 fetch로 가져온 뒤 merge 해야 한다.
fetch = bring (가져오다)
- CPU가 명령어를 가져올 때도 fetch라 하고
- Git에서는 원격 저장소의 내용을 로컬로 가져오기만 한다. (자동 병합은 아님)
그 다음 merge로 합친 뒤 push 한다.

👉 비유: 원주민 땅에 외부 세력이 들어올 때 무조건 충돌이 생긴다. 충돌을 피하려면 먼저 맞춰줘야 한다.

7. Push와 Pull Request

로컬에서 정리한 뒤 push 하면, 이제 깃허브 원격 저장소에 반영된다.
팀장이 확인 후 Compare & Pull Request 버튼을 눌러 PR을 생성하면 된다.
최종적으로 main에 병합하는 건 팀장의 권한이다.

👉 비유: 강남 클럽 보디가드처럼 팀원의 코드가 바로 본 저장소에 들어가지 않고, 먼저 팀원 개인 저장소(origin)에 올라간 후, 팀장이 확인 후에야 메인 저장소(upstream)에 반영된다.

8. 실습하면서 헷갈렸던 부분 메모

이클립스에서 Git Staging, Git Repository 탭 띄우는 거 깜빡함
커밋 이후 화면이 비워지고 나서 뭘 해야 하는지 순간 까먹음 → Remote 폴더에서 우클릭 후 push
Compare & Pull Request 이후 → main 브랜치에 push 해야 최종 반영됨
unstaged vs staged → add 여부 차이
fetch = 원격 저장소에서 가져오기 (병합은 아님)
Github에는 src 폴더가 있어야 한다. 프로젝트 이름만 있으면 안 된다.
깃허브 링크 2개 중 → 복붙할 수 있는 HTTPS 주소를 사용
merge = main과 master 병합 과정
AWS 관련 주의: 클라우드 서비스는 보안 철저히. 카드 등록된 계정 방치 금지.

최종 정리 (명령 순서)

fetch → 원격 변경 사항 가져오기
merge → 로컬과 병합
add → 작업 파일을 Staged로 올리기
commit → 로컬 저장소에 저장
push → 원격 저장소에 올리기
pull request → 팀장 확인
confirm → main 반영

이 블로그 검색

Faith & Tech