Archive

05 Server (Remote)

14 min read

1. 원격 저장소

  • 원격(remote) 저장소 또는 서버 저장소

    • 로컬 저장소에 있는 코드의 복사본을 저장하는 외부 공간

  • 목적

    • 코드 백업: 코드를 안전하게 보관할 수 있다.
    • 협업: 다른 개발자들과 코드를 공유하여 함께 개발을 진행할 수 있다.
    • 연속된 작업: 여러 컴퓨터에서 코드를 동기화하여 어디서든 작업을 이어갈 수 있다.

  • 분산형 모델: 깃(Git)은 여러 개발자가 인터넷 연결이 불안정한 환경에서도 작업할 수 있도록 분산형 모델을 채택했다.

2. GitHub 서버 준비

  • 깃 서버: 직접 깃 서버를 구축할 수도 있지만, 안정적으로 운영하기는 어렵다.

  • 깃 호스팅 서비스: 깃허브(GitHub)와 같은 전문 호스팅 서비스를 이용하면 서버 관리 없이 쉽게 원격 저장소를 운영할 수 있다.

  • 깃허브 저장소 생성

    1. 저장소의 소유자(개인 계정)와 이름을 지정한다. 저장소 이름은 소유자 내에서 중복될 수 없다.
    2. 저장소 주소는 https://github.com/사용자이름/저장소이름 형식을 가진다.

  • cf. 원격 저장소 서비스

    • GitHub(깃허브)
    • GitLab(깃랩)
    • BitBucket(비트버킷)
    • Microsoft Azure DevOps

3. 깃허브 연동 및 원격 등록

3.1. 프로토콜

  • 프로토콜 출제
    • 깃은 서버와 통신하기 위해 여러 프로토콜(Local, HTTP, SSH, Git)을 지원한다.
    • 깃허브는 주로 암호화된 HTTP인 HTTPS와 보안이 강화된 SSH를 사용한다.

(1) Local

  • 개념: 내 컴퓨터의 다른 폴더를 원격 저장소처럼 사용하는 방식(NFS; Network File System)
  • 특징: 가장 빠르고 간단하지만, 모든 자료가 내 컴퓨터에만 있어 백업 관점에서는 위험하다.

(2) HTTP/HTTPS

  • 개념: 아이디와 비밀번호를 이용해 웹 주소(URL)로 접속하는 가장 일반적인 방식
  • 특징: 깃허브(GitHub) 같은 대부분의 호스팅 서비스가 기본으로 지원한다. HTTP는 암호화되지 않아 보안을 위해 암호화된 HTTPS를 사용한다.

(3) SSH

  • 개념: 아이디/비밀번호 대신, 미리 등록된 인증키를 사용해 접속하는 보안이 강화된 방식
  • 특징: 깃(Git)에서 권장하는 방식으로, 한번 설정해두면 비밀번호 입력 없이 안전하게 통신할 수 있어 선호된다. 익명으로 접속할 수 없다.

(4) Git

  • 개념: 깃 전용으로 만들어진 매우 빠른 통신 방식 (깃의 데몬 서비스를 위한 전용 프로토콜)
  • 특징: 별도의 인증 기능이 없어 보안에 취약하기 때문에, 일반적으로 잘 사용되지 않는다.

3.2. 원격 저장소 등록

  • 연결 방법

    1. 먼저 원격 저장소를 생성하고, 이후 로컬 저장소를 연결하는 방법 → 5. clone & pull
    2. 먼저 로컬 저장소를 생성하고, 이후 원격 저장소를 연결하는 방법 → Dev., 06 Branch

  • 원격 저장소 등록: 로컬 저장소와 원격 저장소를 연결하는 과정이다.

    1. 로컬 저장소 생성: git init 명령어로 내 컴퓨터에 깃 저장소를 만든다.
    2. 원격 저장소 추가: git remote add <별칭> <원격저장소URL> 명령어로 원격 저장소를 등록한다. 보통 origin이라는 별칭을 사용한다.
    3. 연결 확인: git remote -v 명령어로 연결된 원격 저장소의 목록과 주소를 확인한다.
git remote # 원격 저장소의 별칭
git remote -v # 원격 저장소의 별칭과 URL
git remote show origin
 
git remote rename origin origin2
git remote rm origin

4. 서버 전송 (push)

동기화: Local to Remote

  • push
    • 로컬 저장소에서 작업하고 커밋(commit)한 내용을 원격 저장소로 업로드하는 작업이다.
    • 로컬의 변경 이력을 서버에 전송하여 다른 사람과 공유하거나 개인 작업을 백업하는 데 사용된다.
git push <원격_저장소_별칭> <로컬_브랜치_이름>
git push origin master

  • cf. 동작 방식

    • 지정한 로컬 브랜치의 내용이 원격 저장소의 같은 이름의 브랜치로 전송된다.
    • 이때 원격 저장소에는 없는, 즉 로컬 저장소에만 새로 추가된 커밋들만 골라서 전송한다.
    • 만약 원격 저장소에 해당 이름의 브랜치가 없다면 push 과정에서 자동으로 새로 생성된다.

  • cf. push가 거부(reject)될 때

    • 다른 사람이 내가 작업하는 동안 원격 저장소에 새로운 내용을 먼저 push한 경우, 내 로컬 저장소는 최신 상태가 아니게 된다. 이 상태에서 push를 시도하면 push가 거부(rejected)된다.
    • 이러한 문제를 해결하기 위해, git push를 하기 전에는 git pull을 먼저 실행하는 것이 좋다.

5. 자동으로 내려받기 (clone & pull)

  • clone
    • 원격 저장소의 모든 내용을 통째로 내 컴퓨터에 복제하여 새로운 로컬 저장소를 만드는 작업이다.
    • 최초 한 번만 실행하며, 원격 저장소 연결 설정도 자동으로 완료된다.
git clone <원격저장소URL>
  • pull (fetch + merge)
    • 이미 clone한 저장소에서, 원격 저장소에 새로 추가된 변경 사항(커밋)을 가져와 내 로컬 저장소에 자동으로 병합(merge) 하는 작업이다.
    • 주기적으로 실행하여 로컬 저장소를 최신 상태로 유지한다.
git pull

6. 수동으로 내려받기 (fetch + merge)

동기화: Remote to Local

  • fetch vs. pull

    • pull: 내려받기 + 자동 병합
    • fetch: 내려받기 + 수동 병합

  • fetch

    • 원격 저장소의 최신 커밋 내용을 가져오기만 하고, 로컬 브랜치에 자동으로 병합하지 않는다.
    • 협업 시 다른 사람의 작업 내용을 먼저 확인하고 병합하고 싶을 때 유용하다.
git fetch
  • merge
    • fetch로 내려받은 내용을 현재 작업 브랜치에 수동으로 병합하는 작업이다.
git merge <원격저장소_별칭>/<브랜치_이름>
git merge origin/master

7. 순서 (협업 시 작업 흐름)

  • 충돌(Conflict): 여러 개발자가 같은 파일의 동일한 부분을 수정하고 서버에 올리면 충돌이 발생할 수 있다.

  • 충돌 방지 원칙: 깃은 원격 저장소보다 내 로컬 저장소가 최신 상태일 때만 push를 허용하여 충돌을 최소화한다.

  • 권장 작업 순서: pull → 코딩 → commit → pull → push

    1. pull: 작업을 시작하기 전, 서버의 최신 내용을 받아온다.
    2. coding: 코드를 수정하고 기능을 개발한다.
    3. commit: 작업한 내용을 로컬 저장소에 기록한다.
    4. pull: 내 코드를 서버에 올리기 직전, 다른 사람이 올린 최신 코드가 있는지 다시 확인하고 받아온다.
    5. push: 모든 변경 사항이 통합된 내 코드를 서버에 올린다.

8. 정리

  • 깃은 코드 이력 관리뿐만 아니라, 원격 저장소를 통해 강력한 협업 도구로 사용된다.
  • 원격 저장소는 코드 공유와 백업의 중심 역할을 하며, 특히 오픈 소스 프로젝트의 활성화에 크게 기여했다.
  • push, pull, fetch 등의 명령어를 통해 로컬과 원격 저장소의 데이터를 동기화하며 개발을 진행한다.

Dev.

cf. 최초 동기화: Local to Remote

  • 이미 작업하던 로컬 Git 저장소가 있을 때, 새로 생성한 비어있는 원격 저장소(GitHub 등)에 코드를 올리는 과정이다.
git init
git remote add origin <원격 저장소 주소>
git branch -M master # 현재 브랜치 이름을 master로 변경
git push -u origin master

  1. 원격 저장소 연결 (git remote add)

    • 로컬 저장소에 origin이라는 이름으로 원격 저장소의 주소를 등록하여 연결 통로를 만든다.
    • origin은 원격 저장소를 가리키는 기본 별칭이다.

  2. 기본 브랜치 이름 확인/변경 (git branch -M)

    • 원격 저장소의 기본 브랜치 이름(주로 master 또는 main)과 로컬 브랜치 이름을 일치시켜 혼란을 방지한다.

  3. 원격 저장소로 업로드 (git push)

    • 로컬 저장소의 커밋 내역을 지정한 원격 저장소의 브랜치로 전송(push)한다.
    • -u 옵션은 로컬의 현재 브랜치와 원격의 특정 브랜치를 한 번만 연결해주는 역할을 한다.

cf. GitHub Pull Request(PR)

  • Pull Request(PR)는 다른 사람의 코드나 프로젝트에 내가 변경한 내용을 적용해달라고 공식적으로 요청하는 기능이다. 주로 코드 리뷰와 협업을 위해 사용되며, 다음과 같은 두 가지 주요 용도로 활용된다.

(1) 권한이 없는 저장소에 코드 변경을 제안할 때

  • 내가 직접 수정할 권한이 없는 공개된 오픈 소스 프로젝트 등에 기여하고 싶을 때 사용한다.

  • 작업 절차

    1. Fork: 원본 프로젝트 저장소를 내 계정으로 그대로 복제한다.
    2. 수정: 내 계정으로 복제된 저장소(forked repository)에서 코드를 수정하거나 새로운 기능을 추가하고 커밋(commit)한다.
    3. Pull Request 생성: 수정한 내용을 원본 프로젝트에 반영해달라고 Pull Request를 보낸다.
    • 결정: 원본 프로젝트의 관리자는 제안된 코드를 검토(리뷰)한 후, 병합(merge)할지 여부를 결정한다.

(2) 프로젝트 내에서 브랜치(Branch)를 병합할 때

  • 하나의 프로젝트를 여러 명의 팀원(공동 작업자)과 함께 개발할 때 안전하고 체계적인 코드 통합을 위해 사용된다.

  • 작업 절차

    1. 브랜치 생성 및 작업: main 또는 master 브랜치에서 새로운 기능 개발이나 버그 수정을 위한 별도의 브랜치(예: feature/login)를 만든다.
    2. 작업 완료 후 Push: 해당 브랜치에서 작업을 완료한 뒤, 원격 저장소에 push한다.
    3. Pull Request 생성: 작업한 브랜치를 main 브랜치에 병합(merge)해달라고 동료 작업자에게 Pull Request를 보낸다.
    • 결정: 동료 작업자들은 변경된 코드를 함께 리뷰하고, 피드백을 주고받는다. 리뷰가 완료되고 문제가 없다고 판단되면 main 브랜치로 병합하여 모든 팀원의 작업 내용을 통합한다.

그래프 뷰

백링크