Git vs GitHub – 버전 제어 란 무엇이며 어떻게 작동합니까?

Git과 GitHub가 어떻게 작동하는지 혼란스러워하신 적이 있습니까? 초조해하지 마십시오. 당신은 혼자가 아닙니다. Git과 GitHub는 때때로 까다로울 수 있지만이 게시물이 끝나면 두 가지를 잘 이해할 수 있습니다.

처음에는 Git과 GitHub가 동일하다고 믿고 싶을 수 있습니다. 그러나 실제로는 그렇지 않습니다. 실제로 GitHub 없이도 Git을 사용할 수 있습니다! 그리고 궁극적으로 둘은 서로 다른 목적으로 존재합니다.

이 게시물은 Git 및 GitHub의 목적을 잘 살펴 보는 것으로 시작됩니다. 나중에이 두 가지 핵심 기술의 주요 차이점에 대해 알아 봅니다.

더 이상 고민하지 않고 Git으로 시작하겠습니다.

힘내는 무엇입니까?

Git은 DVCS (Distributed Version Control System)로 파일 (또는 파일 집합)의 다른 버전을 저장하여 모든 버전을 마음대로 검색 할 수 있도록합니다.

Git을 사용하면 다른 파일 버전을 쉽게 기록하고 비교할 수 있습니다. 즉, 변경된 내용, 변경 한 내용 또는 문제를 시작한 사람에 대한 세부 정보를 언제든지 검토 할 수 있습니다.

하지만 Git이 분산 버전 제어 시스템이라면 정확히 무슨 의미일까요?

"분산"이란 무엇을 의미합니까?

"분산"이라는 용어는 Git에 프로젝트 디렉토리를 공유하도록 지시 할 때마다 Git이 최신 파일 버전 만 공유하지 않음을 의미합니다. 대신 해당 프로젝트에 대해 기록한 모든 버전을 배포합니다.

이 "분산"시스템은 다른 버전 관리 시스템과는 뚜렷한 대조를 이룹니다. 사용자가 중앙 / 로컬 데이터베이스에서 명시 적으로 체크 아웃 한 단일 버전 만 공유합니다.

좋아요,“분산”이란 Git이 기록한 프로젝트 파일의 모든 버전을 배포 하는 것을 의미 합니다. 하지만 버전 관리 시스템이란 정확히 무엇입니까?

버전 관리 시스템이란 무엇입니까?

VCS (Version Control System)는 나중에 참조 할 수 있도록 파일 버전을 저장하는 데 사용되는 방법을 의미합니다 .

직관적으로, 많은 사람들이 이미 버전 제어와 같은 다양한 방법으로 같은 파일의 다른 버전 이름을 변경하여 자신의 프로젝트 blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, 등. 그러나이 접근 방식은 오류가 발생하기 쉽고 팀 프로젝트에 효과적이지 않습니다.

또한 변경된 내용, 변경 한 사람, 변경된 이유를 추적하는 것은이 전통적인 접근 방식으로 지루한 작업입니다. 이것은 Git과 같은 안정적이고 협력적인 버전 관리 시스템의 중요성을 보여줍니다.

그러나 Git을 최대한 활용하려면 Git이 파일을 처리하는 방법을 이해하는 것이 중요합니다.

Git의 파일 상태

Git에는 파일이 수정 된 상태 , 준비된 상태 또는 커밋 된 상태 가 될 수있는 세 가지 기본 상태 (조건)가 있습니다 .

수정 된 상태

수정 된 상태의 파일은 수정되었지만 커밋되지 않은 (기록되지 않은) 파일입니다.

즉, 수정 된 상태의 파일은 수정했지만 Git에 모니터링하도록 명시 적으로 지시하지 않은 파일입니다.

단계적 상태

준비된 상태의 파일은 현재 상태 (버전)에서 선택 .git되어 다음 커밋 스냅 샷 중에 저장소에 저장 (커밋) 될 준비가 된 수정 된 파일입니다 .

파일이 준비되면 해당 파일의 버전을 모니터링 할 수 있도록 Git에 명시 적으로 권한을 부여했음을 의미합니다.

커밋 된 상태

커밋 된 상태의 파일은 .git저장소에 성공적으로 저장된 파일 입니다.

따라서 커밋 된 파일은 준비된 버전을 Git 디렉터리 (폴더)에 기록한 파일입니다.

참고 : 파일의 상태는 Git이 파일을 배치 할 위치를 결정합니다.

파일 위치

Git으로 버전을 제어하는 ​​동안 파일의 주요 위치에는 작업 디렉토리 , 스테이징 영역 또는 Git 디렉토리의 세 가지가 있습니다.

작업 디렉토리

작업 디렉토리는 프로젝트 파일의 로컬 폴더입니다. 즉, 시스템의 모든 위치에 생성 된 폴더는 작업 디렉토리입니다.

노트 :

  • 수정 된 상태의 파일은 작업 디렉토리에 있습니다.
  • 작업 디렉토리는 디렉토리와 다릅니다 .git. 즉, Git이 디렉터리를 만드는 동안 작업 디렉터리를 만듭니다 .git.
  • 두 저장소의 차이점에 대해서는이 비교 문서를 확인하십시오.

준비 영역

스테이징 영역 (기술적으로 Git 용어로 "인덱스"라고 함)은 일반적으로 .git디렉토리에있는 파일로, .git디렉토리에 커밋 될 파일에 대한 정보를 다음 줄에 저장합니다 .

노트 :

  • 준비된 상태의 파일은 준비 영역에 있습니다.

Git 디렉터리

.git디렉토리는 Git이 추적하도록 지시 한 작업 디렉토리 내에 생성하는 폴더 ( "repository"라고도 함)입니다.

또한 .git폴더는 Git이 모니터링하도록 지시 한 파일의 메타 데이터와 개체 데이터베이스를 저장하는 곳입니다.

노트 :

  • .git디렉토리는 망할 놈의 생명입니다 - 당신이 다른 컴퓨터에서 저장소를 복제 할 때 복사 한 항목 (또는 GitHub의 같은 온라인 플랫폼에서)입니다.
  • 커밋 된 상태의 파일은 Git 디렉터리에 있습니다.

기본 Git 워크 플로

Git 버전 제어 시스템으로 작업하는 것은 다음과 같습니다.

Git 기본 워크 플로 다이어그램
  1. 작업 디렉토리에서 파일을 수정하십시오.

    변경 한 모든 파일은 수정 된 상태 의 파일이됩니다 .

  2. .git디렉토리 에 커밋 할 파일을 선택적으로 준비합니다 .

    스테이징 영역에 스테이징 (추가)하는 모든 파일은 스테이징 된 상태 의 파일이됩니다 .

    또한 준비된 파일은 아직 .git데이터베이스에 없습니다 .

    스테이징은 스테이징 된 파일에 대한 정보가 .git저장소 의 파일 ( "인덱스"라고 함)에 포함됨을 의미 합니다.

  3. .git디렉토리에 준비한 파일을 커밋합니다 . 즉, 준비된 파일의 스냅 샷을 .git데이터베이스에 영구적으로 저장 합니다.

    .git디렉토리에 커밋 한 모든 파일 버전 은 커밋 된 상태 의 파일이됩니다 .

지금까지의 요점

지금까지 모든 논의의 장단점은 Git이 유능한 파일 버전 관리, 관리 및 배포를위한 뛰어난 버전 제어 시스템이라는 것입니다. Git을 효율적으로 사용하는 방법을 알아 보려면이 간단한 가이드를 확인하세요.

하지만 잠시만 기다려주세요. Git이 프로젝트 파일의 여러 버전을 효과적으로 관리하고 배포하는 데 도움이된다면 GitHub의 목적은 무엇일까요?

GitHub 이해하기

GitHub는 사용자가 Git 리포지토리를 호스팅 할 수있는 웹 기반 플랫폼입니다. 언제든지 누구와도 프로젝트를 쉽게 공유하고 협업 할 수 있도록 도와줍니다.

GitHub는 또한 다른 사용자의 저장소에있는 파일을 안전하게 편집 할 수있는 방법을 제공하여 오픈 소스 프로젝트에 더 많은 참여를 장려합니다.

GitHub에서 Git 리포지토리를 호스팅 (또는 공유)하려면 다음 단계를 따르세요.

1 단계 : GitHub 계정 등록

GitHub에서 호스팅을 시작하는 첫 번째 단계는 개인 계정을 만드는 것입니다. 등록하려면 공식 등록 페이지를 방문하십시오.

2 단계 : GitHub에서 원격 리포지토리 만들기

계정에 가입 한 후 공유하려는 Git 리포지토리에 대한 홈 (리포지토리)을 GitHub에 만듭니다.

3 단계 : 프로젝트의 Git 디렉터리를 원격 저장소에 연결

프로젝트에 대한 원격 저장소를 만든 후에는 .git시스템에 로컬로 있는 프로젝트의 디렉터리를 GitHub의 원격 저장소에 연결합니다.

원격 저장소에 연결하려면 로컬 터미널을 통해 공유하려는 프로젝트 의 루트 디렉터리로 이동 하고 다음을 실행합니다.

git remote add origin //github.com/yourusername/yourreponame.git

노트 :

  • yourusername위 코드에서 GitHub 사용자 이름으로 바꿉니다 .

    마찬가지로 yourreponame연결하려는 원격 저장소의 이름으로 바꿉니다.

  • 위의 명령은 git 이 로컬 디렉터리가 상호 작용할 수 있는 원격 참조로 로컬 프로젝트에 지정된 URL추가 해야 함을 의미합니다 ..git
  • origin위 명령 의 옵션은 Git이 원격 저장소를 호스팅하는 서버에 제공하는 기본 이름 (짧은 이름)입니다.

    즉, 서버의 URL 대신 Git은 짧은 이름을 사용합니다 origin.

  • 서버의 기본 이름을 고수 할 필요는 없습니다. 대신 다른 이름을 선호하는 경우 위 명령의 이름을 원하는 이름으로 origin대체하십시오 .origingit remote add
  • 서버의 짧은 이름 (예 origin:)은 특별한 것이 아님을 항상 기억하십시오   ! 서버의 URL을 쉽게 참조 할 수 있도록 로컬로만 존재합니다. 따라서 쉽게 참조 할 수있는 짧은 이름으로 변경하십시오.
  • 기존 원격 URL의 이름을 바꾸려면 다음 git remote rename과 같은 명령을 사용하십시오 .
git remote rename theCurrentURLName yourNewURLName
  • 원격 저장소를 복제 (다운로드) 할 때마다 Git은 해당 저장소의 URL 이름을 자동으로 지정합니다 origin. 그러나 git clone -o yourPreferredName명령 으로 다른 이름을 지정할 수 있습니다 .
  • 같은 별명에 대해 저장된 정확한 URL을 참조하려면 origin, 실행 git remote -v명령을 사용합니다.

4 단계 : 연결 확인

Git 디렉터리를 원격 저장소에 연결했으면 git remote -v명령 줄에서 실행하여 연결에 성공했는지 확인합니다 .

그런 다음 출력을 확인하여 표시된 URL 이 연결하려는 원격 URL 과 동일한 지 확인합니다 .

노트 :

  • HTTPS URL 대신 SSH URL을 사용하여 연결하려면 "SSH로 연결"문서를 참조하십시오.
  • 그러나 사용할 원격 URL이 확실하지 않은 경우 "어떤 원격 URL을 사용해야합니까?"를 확인하십시오. 조.
  • 원격 URL을 변경 하시겠습니까? 리모컨의 URL을 변경하는 것은 훌륭한 가이드입니다.

5 단계 : 로컬 Git 리포지토리를 원격 리포지토리로 푸시

로컬 디렉터리를 원격 저장소에 성공적으로 연결 한 후 로컬 프로젝트를 업스트림으로 푸시 (업로드) 할 수 있습니다.

원격 저장소의 다른 곳에서 프로젝트를 공유 할 준비가 될 때마다 Git에 로컬 .git디렉토리의 모든 커밋, 브랜치 및 파일을 원격 저장소 로 푸시하도록 지시하면 됩니다.

로컬 Git 디렉터리를 원격 저장소에 업로드 (푸시)하는 데 사용되는 코드 구문은 git push -u remoteName branchName.

즉, 로컬 .git디렉터리 를 푸시 하고 원격 URL의 짧은 이름이 "origin"이라고 가정하려면 다음을 실행합니다.

git push -u origin master

노트 :

  • 위의 명령은 gitorigin 이라는 URL에 있는 원격 마스터 브랜치에 로컬 마스터 브랜치를 푸시 해야 함을 의미합니다 .
  • 기술적으로이 origin옵션을 원격 저장소의 URL로 대체 할 수 있습니다 . 이 origin옵션은 로컬 .git디렉토리에 등록한 URL의 별명 일뿐 입니다.
  • -u플래그 (업스트림 / 추적 참조 플래그는) 자동으로 연결하는 .git원격 지점으로 디렉토리의 로컬 지점을. 이를 통해 git pull인수없이 사용할 수 있습니다 .

6 단계 : 업로드 확인

마지막으로 GitHub 저장소 페이지로 돌아가 Git이 로컬 Git 디렉터리를 원격 저장소로 성공적으로 푸시했는지 확인합니다.

노트 :

  • 변경 사항을 반영하려면 원격 저장소 페이지를 새로 고쳐야 할 수 있습니다.
  • GitHub에는 원격 저장소를 기능적인 웹 사이트로 변환하는 무료 옵션 기능도 있습니다. 아래의 "방법"을 참조하십시오.

GitHub 페이지로 웹 사이트 게시

프로젝트를 원격 저장소로 푸시 한 후 다음과 같이 웹에 쉽게 게시 할 수 있습니다.

  1. 프로젝트의 기본 HTML 파일 이름이 index.html.
  2. GitHub의 웹 사이트 플랫폼에서 게시 할 프로젝트의 저장소로 이동하여 저장소의 설정 탭을 클릭합니다 .
  3. GitHub 페이지 섹션 까지 아래로 스크롤 하고 소스 브랜치를 none 에서 master로 변경합니다 .
  4. 이후에“귀하의 사이트는 //your-username.github.io/your-github-repo-name/에 게시되었습니다.”라는 알림 이 표시됩니다.
  5. 이제 지정된 URL에서 프로젝트를보고 공개 할 수 있습니다.

이 섹션에서는 GitHub를 사용하여 프로젝트를 게시하는 방법에 대해 간략히 설명했습니다. GitHub 페이지에 대해 자세히 알아 보려면이 "GitHub 페이지 작업"문서를 확인하십시오.

간단히 말해서

GitHub는 Git 리포지토리를 호스팅 (또는 공유)하기위한 온라인 플랫폼입니다. 언제 어디서나 누구와도 프로젝트에서 쉽게 협업 할 수있는 방법을 만들 수 있습니다.

아직도 의심 스럽습니까?

Git과 GitHub 사이의 미세한 경계에 대해 여전히 당황합니까? 걱정하지 마십시오. 다음은 Git과 GitHub의 5 가지 주요 차이점입니다.

차이점 1 : Git 대 GitHub — 기본 기능

Git 은 파일 (또는 파일 집합)의 여러 버전을 기록하는 분산 버전 제어 시스템입니다. 이를 통해 사용자는 기록 된 버전을 언제든지 액세스, 비교, 업데이트 및 배포 할 수 있습니다.

그러나 GitHub 는 주로 Git 리포지토리를 온라인으로 호스팅하기위한 호스팅 플랫폼입니다. 이를 통해 사용자는 원격 저장소를 비공개로 유지하거나 공동 작업을 위해 공개 할 수 있습니다.

차이점 2 : Git 대 GitHub — 운영 플랫폼

사용자는 로컬 머신에 Git을 설치하고 운영합니다. 즉, 대부분의 Git 작업은 인터넷 없이도 수행 할 수 있습니다.

그러나 GitHub는 온라인에서만 작동하는 웹 기반 서비스입니다. 즉, GitHub에서 작업을 수행하려면 인터넷이 필요합니다.

차이점 3 : Git 대 GitHub — 발명가

Linus Torvalds는 2005 년 4 월에 Git 개발을 시작했습니다.

Chris Wanstrath, PJ Hyett, Tom Preston-Werner 및 Scott Chacon은 2008 년 2 월에 GitHub.com을 설립했습니다.

차이점 4 : Git 대 GitHub — 유지 관리자

2005 년 7 월 Linus Torvalds는 Git의 유지 관리를 그 이후로 수석 유지 관리인 Junio ​​C. Hamano에게 넘겼습니다.

그리고 Microsoft는 2018 년 10 월에 GitHub를 인수했습니다.

차이점 5 : Git 대 GitHub — 경쟁자

Git의 인기있는 대안은 Mercurial, TFVC (Team Foundation Version Control), Perforce Helix Core, Apache Subversion 및 IBM Rational ClearCase입니다.

GitHub의 가장 가까운 경쟁자는 GitLab, Bitbucket, SourceForge, Cloud Source Repositories 및 AWS CodeCommit입니다.

전체적으로

Git 및 GitHub는 파일을 관리하고 호스팅하는 데 도움이되는 두 개의 서로 다른 엔터티입니다. 즉, Git은 파일 버전을 제어하는 ​​역할을하며 GitHub는 Git 리포지토리를 호스팅하는 플랫폼입니다.

유용한 자원

  • Git 사용 방법 – 멋진 팁이 담긴 멋진 가이드