git 과 github

Git이란, 버전 관리 시스템(Version Control System, VCS)의 하나이다. 
쉽게 말하면, 말 그대로 '버전'을 관리할 수 있는 수단이다. 수정 사항이나, 업데이트 사항 등을 그때 그때 바로 반영 할 수 있도록 하는 시스템을 말한다.

 

여러 명이 하나의 프로젝트를 개발할 때, 소스코드의 변경 내역을 추적하고 관리하여 버전을 관리할 수 있는 도구입니다. 깃은 빠른 속도와 분산 저장소를 통한 안정적인 관리, 브랜치 기능 등 다양한 기능을 제공하며, 다양한 운영체제에서 사용할 수 있습니다.

 

버전 관리 시스템(Version Control System)이란?

버전 관리 시스템(이하 VCS)은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내 올 수 있는 시스템이다. 많은 개발자들이 소스 코드를 관리할 때 VCS를 사용하지만, 거의 모든 컴퓨터 파일의 버전을 관리할 수 있다.

 

VCS를 사용하면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌리거나 시간에 따라 수정 내용을 비교해 볼 수도 있다. 누가 문제를 일으켰는지 추적할 수 있고 누가 언제 만들어낸 이슈 인지도 알 수 있다. 또한 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다.

 

따라서 VCS를 이용하면 위와 같은 장점을 누릴 수 있다.

 

 

VCS는 다음과 같은 종류로 세분화 된다.

 

로컬 버전 관리(LVCS - Local VCS)

 

 

[그림 1] LVCS (출처 : 참고1)

 

로컬 버전 관리는 로컬 컴퓨터의 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리한다. 즉, 하나의 로컬 컴퓨터에서 파일을 관리하는 방식으로 동작한다.

 

 

중앙집중식 버전 관리(CVCS - Central VCS)

 

[그림 2] CVCS (출처 : 참고1)

 

중앙집중식 버전 관리는 파일을 관리하는 서버가 별도로 존재하고 클라이언트가 중앙 서버에서 파일을 받아서 사용(checkout)한다. 수년간은 많은 개발자들이 CVCS 방식을 사용했다.

 

이러한 CVCS 환경은 LVCS에 비해 장점이 많다. 누가 무엇을 하고 있는지 알 수 있기 때문에 관리자가 좀 더 꼼꼼히 관리할 수 있다. 또한, 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.

 

하지만 CVCS는 몇 가지 치명적인 결함이 존재한다. 만약 중앙 서버에 문제가 발생하면 아무도 다른 사람과 협업할 수 없으며 백업도 할 수 없다. LVCS와 마찬가지로 이런 문제가 발생하면 모든 것을 잃을 수 있다.

 

 

분산 버전 관리(Distributed VCS)

 

[그림 3] DVCS

 

 

분산 버전 관리는 단순히 파일의 마지막 스냅숏을 사용(checkout) 하지 않는다. 저장소를 히스토리와 더불어 통째로 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. 즉, 복제물은 모든 데이터를 가진 진정한 백업이다.

---

Git이란?

 

깃은 분산 버전 관리 시스템(DVCS)의 일종이다. 깃은 형상 관리 도구(Configuration Management Tool)라고도 불린다. 깃은 주로 소프트웨어를 개발하는 소스 코드를 효과적으로 관리할 수 있게 도와주는 무료 오픈 소프트웨어이다.

 

깃은 DVCS의 일종이기 때문에 중앙 저장소가 손상되어도 로컬 저장소를 이용하여 원상복구가 가능하다. 또한 로컬 저장소에서 개발을 진행할 수 있기 때문에 인터넷 연결이 필요하지 않아도 되며, 각각의 개발자들이 브랜치(branch)를 통해 개발한 후 합치는(merge) 방식으로 진행할 수 있기 때문에 협업도 쉬워진다.

 

깃의 공식 홈페이지에 소개된 깃의 특징은 다음과 같다.

 

 

1. Branching and Merging

 

 

 

[그림 4] Branching and Merging

 

 

깃은 브랜치(branch)와 합병(Merge)이라는 개념이 있다. 간단하게 소개하자면 브랜치는 말 그대로 가지(branch)라고 볼 수 있다. 나무에서 여러 갈래로 가지가 뻗어나가는 것처럼, 소스 코드도 여러 개의 가지를 뻗어나갈 수 있다. 새로운 아이디어를 적용시켜보거나, 버그를 고치거나, 이전 버전으로 돌아가거나, 패치를 적용시키거나... 많은 가지들을 만들 수 있으며 이것을 합칠(merge) 수 있다.

 

2. Small and Fast

 

깃은 빠르다. 깃은 거의 모든 동작이 로컬에서 진행되기 때문에 다른 VCS처럼 서버와의 통신에 많은 비용을 들이지 않아도 된다. 또한, 깃은 C언어로 작성되어 있어 속도가 빠르다. 깃의 주요 디자인 목표가 속도와 성능이라고 한다.

 

 

3. Distributed

 

깃은 분산되어 있다. 사용자는 전체 저장소를 복제(clone)해서 로컬 저장소로 가져온다. 이는 수많은 백업들이 분산되어 저장되어 있다는 뜻이다. 따라서 중앙 저장소의 장애를 극복하기 쉬워진다.

 

깃은 분산되어 있기 때문에 쉽게 수 많은 workflow를 가질 수 있다. 이때 수많은 workflow를 합칠 때 문제가 발생할 수 있지만 GitHub 저장소와 같은 것을 사용하여 합병한다면 더 쉽게 관리할 수 있다.

 

 

4. Data Assurance

 

모든 파일과 커밋(commit)은 검증되기 때문에 저장소에 넣은 그대로 변하지 않을 것을 보장한다. 즉, 데이터가 변질되지 않을 것이라고 보장한다. 

 

 

5. Staging Area

 

 

[그림 5] Staging Area

 

 

다른 시스템들과 다르게 깃은 "Staging Area"라는 것을 사용한다. 이것은 커밋이 일어나는 곳으로 커밋이 일어나기 전 검증을 할 수 있는 곳이기도 하다. 커밋은 이 Staging area에서 repository(저장소)로 파일을 보내는 것을 의미한다. 

 

이때 Staging Area는 변한 파일과 변하지 않은 파일을 구분하고 추적하고 있기 때문에 변화가 있는 파일만 빠르게 골라내어 커밋할 수 있다.

 

 

6. Free and Open Source

 

깃은 무료이며 오픈 소스이기 때문에 누구든 사용할 수 있다.

 

 

깃의 동작 원리

깃은 파일의 변경 내역을 추적하여 관리하는데, 이를 '스냅샷(snapshot)'이라고 합니다. 깃은 파일이 변경되면 이전 파일의 상태를 저장하여 변경 내역을 추적합니다. 이렇게 저장된 파일들의 변경 내역을 커밋하면, 커밋의 이력을 통해 파일의 변경 내역을 추적할 수 있습니다.

또한, 깃은 분산 버전 관리 시스템이기 때문에, 로컬 저장소와 원격 저장소의 개념이 존재합니다. 로컬 저장소에서 작업을 하고 커밋한 내용을 원격 저장소에 푸시(push)하여 다른 개발자와 협업할 수 있습니다.

Git 의 주요 개념

• Repository(저장소): 깃에서는 변경 내역을 추적하고 관리하는 단위로, 일반적으로 로컬 저장소와 원격 저장소로 나뉩니다. 로컬 저장소는 개발자의 개발 환경에서 사용되는 저장소이며, 원격 저장소는 다른 개발자와 협업할 때 사용되는 저장소입니다.
• Commit(커밋): 변경 내역을 저장소에 기록하는 작업을 의미합니다. 각각의 커밋은 고유한 해시값을 가지며, 변경 내역의 이력을 추적할 수 있습니다.
• Branch(브랜치): 커밋의 이력을 기반으로 생성된 작업 라인으로, 새로운 기능 추가나 버그 수정 등을 위해 독립적인 브랜치를 생성하여 작업할 수 있습니다.

 

Git을 왜 사용할까?

개발자로서, 수 많은 코드들을 다루고 다른 개발자들과 협업을 진행하다 보면 잦은 업데이트 사항이 생긴다. 그럴 때마다 파일 명을 달리하여 새로 저장 해야 한다면? 한 프로젝트 당 코드 파일만 수 십, 수 백 수 천개가 될 수도 있다.

깃을 사용하면 굳이 이러한 번거로운 과정 없이도 다른 개발자들과 손 쉽게 코드를 주고 받을 수 있으며, 여러 명이 동시에 한 코드를 가지고 작업하는 병렬적인 작업의 진행이 가능하다.

 

A라는 개발자가 코드를 작성하여 B에게 넘겨주고, B가 그 코드를 받아서 진행 한 뒤 C에게 넘겨주는 귀찮은 과정이 필요 없어진 것이다! 여러 브랜치를 형성해 작업한 뒤, 마지막에 합치는 방식을 통해 효율적인 작업이 가능하다.

또한 쉽게 이전 버전으로 이동할 수 있으며 다시 원래의 버전으로 돌아오는 것 또한 자유롭다.

 

 위에서 언급했듯, 깃은 분산 버전 관리 시스템이기 때문에 중앙 서버가 필요 없다. 즉, 인터넷이 연결 되어 있지 않은 상황에서도 작업이 가능하며, 도중에 이상이 생겨 저장소가 날라가버린다고 해도 쉽게 복구할 수 있다.

---

Git과 Github의 연관성?

 깃과 깃 허브는 뗄레야 뗄 수 없는 관계이다.
그렇지만 두 가지 개념에 대해 혼동해서는 안된다!

 깃

• 로컬에서 관리되는 버전 관리 시스템
• 직접 소스 코드를 수정함으로서 버전을 관리
• 소스 코드를 효율적으로 관리할 수 있게 해주는 형상 관리 도구

 깃 허브

• 깃(Git)을 사용하는 프로젝트를 지원
• 개발자들의 버전 제어 및 협업을 위한 하나의 플랫폼
• 클라우드를 통해 관리되는 버전 관리 시스템
• 오픈 소스는 일정 부분 무료로 사용이 가능하나, 대부분 유료 시스템
• 깃처럼 자체적으로 구축하는 시스템이 아닌, 클라우드를 빌려쓰는 개념

 간단히 Git은 로컬에서 버전 관리 시스템을 운영하는 방식이고, Github는 '깃 허브'자체에서 제공해주는 클라우드 서버를 이용한다.

 

따라서 타 개발자들과의 협업 시, Github를 써서 오픈 소스를 공유하거나 타 개발자들과 의견을 교환할 수 있다. 만약 혼자서 작업하거나, 작은 범위에서 진행하는 협업이라면 굳이 Github를 사용하지 않고 Git으로만 진행해도 무방하다.

---

Git의 주요 개념

✔️ 깃을 사용하기 위해서 알아두어야 할 중요한 개념들에 대해 알아보자.

1️⃣ Repository (저장소) : 소스 코드들이 저장되어 있는 물리적인 공간을 의미한다. 저장소를 통해서 작업자가 진행, 변경했던 사항들에 대해 알 수 있다.
작업을 시작할 때 원격 저장소에서 로컬 저장소로 소스 코드를 복사해서 가져오고(Clone), 이후 소스 코드를 변경한 다음 커밋(Commit)한다. 이 때, 커밋한 소스는 로컬 저장소에 저장되며, Push 하기 전에는 원격 저장소에 반영되지 않는다.

2️⃣ Working Tree : 흔히 우리가 사용하는 '폴더'를 말한다.

3️⃣ Index (= Staging Area) : Commit을 실행하기 전의 저장소와 Working tree 사이에 존재하는 공간을 말한다. Working Tree -> Index -> Commit 순의 절차를 거친다.

4️⃣ Commit : 작업 과정들에 대한 점검을 마친 뒤, 저장소에 남기는 과정을 의미한다. 각각의 커밋 단계는 의미 있는 단계이다. 따라서 커밋 로그를 남긴다. git log라는 명령어를 통해 커밋된 사항들에 대해 확인 할 수 있다.

5️⃣ Checkout : 특정 시점이나 branch의 소스 코드로 이동하는 것을 의미한다. 이 과정을 통해 과거 여러 시점의 소스 코드로 이동할 수 있다.

6️⃣ Branch : Commit 단위로 구분된 소스 코드 타임라인에서 분기해서 새로운 commit을 쌓을 수 있는 가지를 만드는 것을 말한다. Branch에서 작업을 완료하면, Merge 작업을 수행한다.

7️⃣ Merge : Branch와 Branch의 내용을 합치는 작업, 즉 병합을 말한다. Branch와는 다소 반대되는 개념이다. 병합 과정 중 두 branch에서 하나의 동일한 파일에서 서로 다른게 수정한 경우 충돌이 발생하며, 병합이 일시정지 된다. 이 때, 충돌 부분에 대해 직접 수정하거나 Merge Tool 등을 활용하여 충돌을 해결한 뒤 병합을 계속 진행한다.

---

Git의 명령어

 깃의 명령어 중 자주 쓰이는 주요 명령어들에 대해 알아 보자.

• git init : 깃 초기화. 이 명령어를 실행해야만 깃이 실행된다. 이 명령어 실행 전까지는 그냥 일반 폴더일 뿐이나, 이후엔 추가적인 명령어들을 통해 작업을 진행 할 수 있다.

• git status : 깃 저장소의 상태를 확인한다. 이 명령어를 통해 현재 상태가 어떤 지 수시로 확인 가능하다.
• git add : 커밋에 파일의 변경 사항을 포함하도록 한다. 이 명령이 저장소에 새 파일들을 직접적으로 추가하진 않는다.
• git commit : "git commit -m '저장명'" 등과 같은 명령어로 주로 사용한다. 이 명령어를 통해 커밋을 생성하고, 변경 사항을 확정하여 반영한다.
• git clone : 기존 소스 코드 다운로드 및 복제한다. 즉, 원격 저장소의 저장소를 로컬에서 이용할 수 있도록 복사해 가져온다.

• git log : 나의 커밋 내역에 대해 알고 싶을 때 사용하면 현재 커밋 목록들을 확인 가능하다.
• git checkout : 브랜치에서 브랜치로 이동 가능하다. 현재 버전에서 이전 버전의 커밋으로 이동하거나 변경 전의 브랜치로 접근 가능하다.
• git checkout master : 이전 버전, 변경 전 브랜치에서 다시 현재의 (master) 브랜치로 되돌아 올 수 있다.
• git push : 소스 코드의 변경 사항을 원격 저장소에 반영한다.
• git pull : 원격 저장소의 변경 내용이 현재 디렉토리로 가져와진 뒤, (fetch) 병합된다.
• git merge : 변경 사항 등이 모두 확정되고 난 후, 브랜치들을 병합한다. 작업 마무리 단계에서 시행한다.

 

 

출처 : https://code-lab1.tistory.com/248

[Git] 깃(Git), 깃허브(GitHub)란? 버전 관리 시스템(VCS)이란? LVCS, CVCS, DVCS란? - Git 기초(0)

https://velog.io/@euisuk-chung/1.-%EA%B9%83Git%EC%9D%B4%EB%9E%80

깃(Git)이란?