협업을 위한 Git 기초 5 | Git & GitHub 연동, 원격 저장소와 협업 흐름

목차

1. 사용자 정보 설정 (git config)
2. 왜 원격 저장소가 필요한가
3. 로컬 저장소 vs 원격 저장소 구조
4. GitHub 저장소 생성
5. origin은 무엇인가
6. git remote add origin
7. git push
8. git pull
9. git fetch
10. git merge
11. git clone
12. 로컬 브랜치 vs 원격 브랜치
13. 협업 흐름 정리

 

1. 사용자 정보 설정 (git config)

 

Github와 연동하기 전에 먼저 커밋 작성자 정보를 설정해야 한다.

 

Git은 각 커밋에 작성자의 이름과 이메일을 기록한다.

$ git config --global user.name "이름"
$ git config --global user.email "이메일"

 

설정이 제대로 되었는지 확인하는 명령어는 아래와 같다.

$ git config user.name
$ git config user.email

 

이메일은 GitHub 계정에 등록된 이메일과 동일하게 설정하는 것이 좋다.
그래야 GitHub에서 커밋 작성자가 자동으로 연결된다.

 

만약 user.name이나 user.email을 수정하고 싶다면 아래 명렁어로 수정 가능하다.

$ git config user.name "이름"
$ git config user.email "이메일"

 

2. 왜 원격 저장소가 필요한가

 

지금까지는 로컬(Local) 환경에서만 작업했다.

하지만 실제 협업 환경에서는 여러 개발작 같은 프로젝트를 함께 작업한다.

 

이때 필요한 것이 원격 저장소(Remote Repository)이다.

여기서 원격 저장소의 역할이 바로 Github이다.

 

3. 로컬 저장소 vs 원격 저장소 구조

구조를 단순화하면 다음과 같다.

 

git & github 구조

 

왼쪽은 개인 작업 공간이다.

• Working Directory : 실제 파일이 존재하는 공간
• Staging Area : 커밋할 파일을 준비하는 공간
• Local Repository : 커밋 이력이 저장되는 공간(.git)

오른쪽은 공유 공간이다.

• Remote Repository : GitHub에 존재하는 저장소

이때 데이터 흐름은 다음과 같다.

 

로컬 내부 흐름

- git add : Workspace의 변경 내용을 Staging Area로 올린다.
- git commit : Staging에 올라온 내용을 하나의 스냅샷으로 만들어 Local Repository에 저장한다.

 

원격과의 연결 흐름

- git push : Local Repository의 커밋을 Remote Repository로 전송한다.
- git fetch : Remote Repository의 변경사항을 Local Repository로 가져온다. (Workspace 반영x)
- git merge : Local Repository에 가져온 변경사항을 현재 브랜치에 병합한다.
- git pull : git fetch + git merge를 한 번에 수행하는 명령어이다. 
- git clone : Remote Repository를 복제하여 Local Repository를 생성하고 기본 브랜치를 자동으로 checkout하여 Worksapce를 구성한다.

 

이제 우리는 단순히 명령어를 외우는 것이 아니라,
Git이 내부적으로 어떤 방향으로 데이터를 이동시키는지를 이해할 수 있다.

 

4. GitHub 저장소 생성

로컬 저장소를 원격 저장소와 연결해야 한다.

GitHub는 우리가 만든 로컬 저장소를 업로드하고, 여러 개발자가 함께 작업할 수 있도록 공유하는 공간이다.

 

먼저 GitHub에 접속하여 새로운 저장소(Repository)를 생성한다.

 

리포지토리 생성 시 Configuration 속성은 아래와 같다.

1. Choose visibility
   • Public : 인터넷상의 누구든지 이 저장소를 볼 수 있다. 커밋 권한은 사용자가 직접 설정할 수 있다.
   • Private : 이 저장소를 볼 수 있는 사람과 커밋할 수 있는 사람을 직접 선택할 수 있다.
2. Add README
   • README란 프로젝트에 대한 정보를 전달할 수 있는 파일이다.
   • 아래와 같은 정보를 보통 포함한다. 
     • 프로젝트는 무엇을 하는지
     • 프로젝트가 유용한 이유
     • 사용자가 프로젝트를 시작하는 방법
     • 사용자들이 프로젝트 관련 도움을 받을 수 있는 곳
     • 누가 이 프로젝트를 관리하고 기여하는지
   • REAME는 Markdown 언어로 작성할 수 있다.
3. ADD .gitignore
   
   • Git에게 추적되지 않는 파일(=커밋 시 무시할 파일 및 디렉터리)을 알려주는 역할이다.
   • .gitignore 파일을 리포지토리에 커밋하면, 리포지토리를 복제하는 다른 사용자와 무시 규칙을 공유할 수 있다.
   • 보통 Git으로 버전 관리를 하면 안 되는 파일은 아래와 같다.
     • node_modules : 용량 크며 보통 다시 설치가 가능하다.
     • .env : 비밀번호/토큰 등 민감정보가 들어있다.
     • 로그(*.log) : 기록용이며 버전 관리는 하지 않는다.
     • IDE 설정(.vscode/) : 사용자마다 다르기 때문이다.
4. ADD license
   • 퍼블릭 리포지토리는 오픈 소스 소프트웨어를 공유하는 데 자주 사용된다.
   • 다른 사용자가 소프트웨어를 자유롭게 사용, 변경 및 배포할 수 있도록 라이선스를 부여해야 한다.

Github에서 저장소를 만들었다고 해서 자동으로 로컬과 연결되지 않는다.

Git은 '어느 원격 저장소와 연결할 것인지'를 직접 지정해줘야 한다.

 

이때 등장하는 개념이 바로 origin이다.

 

 

5. origin은 무엇인가

origin이란 단순히 원격 저장소에 붙이는 별명(alias)이다.

 

Git에서는 원격 저장소를 여러 개 등록할 수 있다. 

예) 회사 서버, 개인 Github, 협업용 GitLab, 테스트용 서버 등

 

이 모든 저장소를 각각 이름으로 구분해야 한다.

그중 기본으로 많이 사용하는 이름이 origin이다.

 

origin이 아닌 다른 이름으로도 설정할 수 있으나, 대부분 프로젝트에서 기본 원격 저장소 이름은 origin이다.

 

6. git remote add origin

 

로컬 저장소와 GitHub 저장소를 연결하는 명령어는 아래와 같다.

$ git remote add "별명" "원격저장소주소"

 

여기서 별명이 origin이 되며, 명령어 예시는 아래와 같다.

$ git remote add origin https://github.com/username/project.git

 

이때 연결이 정상적으로 등록되었는지 확인하는 명령어는 아래와 같다.

$ git remote -v

 

git remote -v의 출력 예시는 아래와 같다.

'-v' 옵션은 verbose의 의미로 상세 모드를 의미한다.

$ git remote -v
origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

 

 

origin이라는 이름(별명)으로 해당 Github 저장소와 연결되어 있으며, fetch와 push 모두 같은 주소를 사용한다는 뜻이다.

• fetch : 가져올 때 쓰는 주소
• push : 보낼 때 쓰는 주소

보통은 fetch/push 주소가 같지만, 다르게 설정할 수도 있어서 둘 다 보여준다.

 

등록한 원격 저장소를 삭제하는 명령어는 아래와 같다.

$ git remote remove origin

 

 

원격 저장소의 이름을 변경하는 명령어를 아래와 같다. (origin → old-origin)

$ git remote rename origin old-origin

 

기존 원격 저장소의 URL을 변경한는 명령어는 아래와 같다.

$ git remote set url "이름" "새원격저장소주소"

 

원격 저장소의 위치가 변경되었거나, 프로토콜에 변경되었거단(예: HTTP에서 SSH),

또는 원래 URL에 오류가 있는 경우에 유용하다.

7. git push

 

 git push 는 로컬 저장소(Local Repository)의 커밋을 원격 저장소(Remote Repository)로 전송하는 명령어이다.

 

기본 명령어는 아래와 같다.

$ git push "원격 저장소 이름" "로컬 브랜치 이름"

 

보통  git push 는 아래와 같이 작성된다.

$ git push origin main

 

즉, 로컬(main)브랜치를 원격 저장소(origin)의 main 브랜치로 업로드하겠다라는 의미이다.

 

처음 push할 때는 보통 아래와 같이 사용한다.

$ git push -u origin main

 

'-u' 옵션은 '--set-upstream'의 줄임말로, upstream을 설정한다는 의미이다.

즉, 로컬 레포지토리와 원격 레포지토리를 연결하는 명령어로, 한 번 사용하면 아래와 같이 단축된 명령어 사용이 가능하다.

 

$ git push
$ git pull

8. git pull

 

 git pull 은 원격 저장소(Remote Repository)의 변경사항을 로컬 브랜치에 반영하는 명령어이다.

 

즉, 원격 저장소의 변경사항을 로컬 저장소로 가져오고 현재 브랜치에 병합한다. 

바로 작업 브랜치에 최신 변경사항을 반영하고자 할 때 유용하다.

 

기본 명령어는 아래와 같다.

git pull "원격 저장소 이름" "로컬 브랜치 이름"

 

보통  git pull   아래와 같이 작성된다.

$ git pull origin main

 

git push -u를 설정하고 난 후는 아래 명령어로 실행가능하다.

$ git pull

 

첨고로   git pull  은  git fetch  +   git merge 를 한 번에 수행하는 명령어이다.

 

9. git fetch

 

 git fetch 는 원격 저장소의 최신 변경사항을 로컬 저장소로만 가져오는 명령어이다.

현재 작업 중인 브랜치와 Workspace에는 아직 반영되지 않는다.

 

기본 명령어는 아래와 같다. 기본적으로 현재 설정된 원격 저장소(보통 origin)의 모든 브랜 정보를 가져온다.

$ git fetch

 

특정 원격 저장소를 가져오는 명령어는 아래와 같다.

$ git fetch origin

 

특정 원격 저장소의 특정 브랜치만 가져오는 명령어는 아래와 같다.

$ git fetch origin main

 

 git fetch  의 장점은 변경 내용을 합치기 전 미리 내용을 확인할 수 있다는 것이다.

fetch를 실행한 후 git log로 원격 브랜치의 새로운 커밋을 확인할 수 있다.

 

예

$ git log main..origin/main --oneline

 

위 명령어의 의미는 현재 로컬 main에는 없지만 origin/main에만 존재하는 커밋임을 의미한다.

 

10. git merge

 

 git merge 는 서로 다른 브랜치의 변경사항을 하나로 합치는 명령어이다.

보통  git fetch  이후 가져온 원격 변경사항을 현재 작업 중인 브랜치에 반영하기 위해 사용한다.

 

기본 명령어는 아래와 같다.

$ git merge "병합할 브랜치"

 

원격 변경사항을 병합할 때는 보통 다음과 같이 사용한다.

$ git merge origin/main

 

이 명령어는 origin/main 브랜치의 변경사항을 현재 체크아웃된 브랜치(main 등)에 병합한다.

 

병합이 완료되면 Workspace의 파일도 함께 업데이트된다.

 

 

12. git clone

 

 git clone 은 원격 저장소를 처음 복제할 때 사용하는 명령어이다.

$ git clone "원격저장소주소"

 

예시는 아래와 같다.

$ git clone https://github.com/username/project.git

 

이 명령어는 Remote에서 Local 그리고 Local에서 Workspace까지 한 번에 생성하는 명령어이다.

보통 프로젝트에 처음 참여하는 개발자가 사용한다.

13. 로컬 브랜치 vs 원격 브랜치

 

Git에는 두 종류의 브랜치가 있다.

1. 로컬 브랜치(Local Branch)
2. 원격 추적 브랜치(Remote-tracking Branch)

로컬 브랜치는 로컬 저장소에 존재하는 브랜치로 내가 실제로 작업하는 브랜치이다.

예 : main, dev, feature/login ...

 

현재 어떤 브랜치에서 작업 중인지 확인하려면 아래 명령어를 사용하여 확인할 수 있다.

$ git branch

 

 

원격 추적 브랜치는 원격 저장소의 상태를 로컬에 복사해둔 브랜치이다.

예 : origin/main, origin/dev ...

 

여기서 origin은 원격 저장소의 이름, main은 그 저장소의 브랜치 이름을 의미한다.

 

사용자가 직접 이동할 수 없는 로컬 참조이며, 사용자가 마지막으로 원격 저장소와 통신한 시점(변경 사항을 가져오거나, 푸시하거나, 풀한 시점)의 브랜치 상태를 반영한다.

 

14. 협업 흐름 정리

 

 

Git&GitHub 협업 흐름

 

시나리오
1. B가 처음 참여 (git clone)
2. A가 작업 후 GitHub에 업로드 (git add, git commit, git push)
3. B가 작업 전 변경 사항 확인 (git fetch)
4. B가 충돌 문제 확인 후 변경사항 반영 (git merge)
5. B가 작업 후 GitHub에 업로드 (git add, git commit, git push)
6. A가 변경사항 반영 (git pull)

 

지금까지 우리는 로컬 저장소와 원격 저장소를 연결하고, push, fetch, merge, pull을 통해 협업 흐름을 완성했다.

하지만 실제 팀 프로젝트에서는 개발자가 직접 main 브랜치에 바로 병합하는 경우는 드물다.

 

대신, 브랜치를 생성하고 코드 리뷰를 거쳐 병합하는 방식이 사용된다.

이 과정의 핵심이 바로 Pull Request(PR)이다.

 

다음 글에서는 Pull Request가 왜 필요한지, 그리고 협업에서 어떤 역할을 하는지 구조적으로 살펴보겠다.

 

---

👉 협업을 위한 Git 기초 6 | Pull Request(PR)와 코드 리뷰 구조 이해