깃(Git)과 깃허브(Github)

Ouroboros·2023년 8월 27일

git github

개발상식

목록 보기

3/17

0. 버전 관리 시스템

Version Control System(VCS)
파일의 수정했던 기록(버전)들을 저장할 수 있는 시스템
VCS를 사용하면 파일 하나 하나 뿐만 아니라 프로젝트 전체를 이전 버전으로 되돌릴 수 있음
VCS를 이용하여 코드 수정 내용을 확인할 수 있으며, 누가 언제 만든 이슈인지 파악할 수 있고 실수로 삭제를 하더라도 복구가 가능
세 종류의 버전 관리 시스템을 가지고 있다(Local, CVSC, DVSC)

1) 로컬 버전 관리 시스템

데이터베이스를 사용해서 파일의 변경 정보를 관리
VCS 도구 중에 RCS(Revision Control System)라고 부르는 것이 대표적
RCS는 변경되는 부분(Patch set)을 관리하며, 이 Patch Set은 특별한 파일 형식으로 저장
이 Patch Set를 통해서 모든 파일을 특정 시점으로 되돌림
간단하지만 실수하기 쉬운 단점이 존재

2) 중앙집중식 버전 관리 시스템(CVCS)

함께 개발하여 작업해야하는 상황들 때문에 개발된 방식
CVS, Subversion, Perforce 같은 시스템이 대표적
서버가 별도로 있고 클라이언트가 중앙 서버(원격저장소)에서 파일을 받아서 사용
장점 : 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나만 관리하면 되므로 효율적
관리자로서 누가 어떤 일을 하는지 꼼꼼하게 확인과 관리가 용이
단점 : 중앙서버에서 문제가 생기면 치명적
중앙 서버에 문제가 발생할 동안 백업을 할 수 없고 다른 사람들과 협업을 불가능
또한 중앙 데이터터베이스에 문제가 생기면 히스토리를 잃을 수 있는 치명적 단점 존재

3) 분산 버전 관리 시스템(DVCS)

참여자들의 각 컴퓨터 디스크(로컬 저장소)에 프로젝트 파일들을 1차적으로 저장하고
사용자의 명령에 따라 Github, Bitbucket과 같은 원격 저장소(서버 저장소)에도 저장
Git, Mecurial, Bazaar, Darcs가 대표적
단순히 파일의 마지막을 checkout 하지 않고, 저장소 전체와 히스토리를 전부 복제함
따라서 한 쪽에 문제가 생겨도 한 쪽에서 데이터를 가져와 복원하면 되기 때문에 복구가 용이

👀 비교 정리

커밋 순서
CVCS : 참여자 -> 원격 저장소
DVSC : 참여자 -> 로컬 저장소 -> 원격 저장소

1. 깃(Git)

개인 컴퓨터에 돌아가는 VCS
소스코드 버전 사이를 이동하며 새로운 소스코드를 추가하거나 삭제할 수 있는 기능을 제공
로컬에서 사용한다면 개인 계정 등록과 인터넷 연결이 필요 없음❌
Git은 데이터를 저장할 공간만 있다면 어디서나 사용 가능
usb에 저장할 수도 있고, 네이버 클라우드나 구글 드라이브에도 업로드하여 다른 개발자들과 협업이 가능하다.

2. 깃허브(Github)

Git으로 관리하는 프로젝트를 올려둘 수 있는 대표적인 클라우드
Github라고 불리는 회사의 서버에 올리는 것
따라서 개인 계정 등록과 인터넷 연결이 되어야 사용🆗

3. 깃과 깃허브의 차이점

1) 저장소

Git은 데이터를 공간만 있으면 어디에서든 저장이 가능하다.
개인 컴퓨터에만 저장하여 혼자 사용할 수 있고, USB에 저장한다면 휴대하면서 내가 만든 프로젝트를 사용할 수 있다. 드롭박스, 구글 드라이브와 같은 클라우드 서버에 올려둔다면 다른 사람들과 협업이 가능하다.
반면, Github는 Git을 Github회사에서 제공하는 서버에 저장한다.

2) 계정과 인터넷 연결

핸드폰이나 노트북에 파일을 저장할 때 따로 계정이나 인터넷 연결이 필요하지 않다. 하지만 클라우드에 업로드하거나 클라우드에 이미 업로드된 파일을 내려받을 땐 해당 클라우드의 계정이 필요하며 인터넷에 연결되어 있어야 한다.

이처럼 Git으로 로컬저장소에만 저장하려고 하면 계정과 인터넷 연결이 따로 필요하지 않다.
하지만 Github를 이용하려고 할때엔 Github의 계정과 인터넷 연결이 필수이다.

3)Pull Request

PR은 Github에서 제공하는 기능이다.
Merge(변경사항을 코드에 적용)하기 전에 다른 협업자에게 확인을 받는 절차이다. Reviewer가 자신이 작업한 코드에 대해 리뷰를 하고 AssigneesPR(작업의 담당자)가 그것을 확인하고 승인(Approve)과 승인거부(Request changes)를 체크한다.
이 과정은 다른 협업자와 커뮤니케이션을 용이하게 해주고 코드의 품질을 유지할 수 있게 도와준다.