[KT 에이블스쿨 8기] GIT과 GIT HUB는 무엇일까 ?

Git이란?

Git은 파일의 변경 이력을 시간 순서대로 기록하고 관리하는 분산 버전 관리 시스템(DVCS)이다.

이 시스템을 통해 특정 시점의 파일 상태로 언제든지 돌아갈 수 있으며,

과거 버전과 현재 버전을 비교하여 어떤 내용이 바뀌었는지 쉽게 파악할 수 있다.

특히 여러 명이 함께 작업하는 협업 프로젝트에서 각자의 변경 사항을 체계적으로 통합하고 관리할 수 있어 매우 유용하다.

 

 

 

 

버전 관리 시스템 (Version Control System, VCS)

'보고서_최종.hwp', '보고서_진짜최종.hwp', '보고서_교수님피드백반영.hwp'...

중요한 문서를 수정할 때마다 원본을 잃을까 불안해 파일을 복사하며 관리해 본 경험이 있을 것이다.

결국 어느 것이 진짜 최종본인지 헷갈리는 상황에 이르곤 한다.

버전 관리 시스템(Version Control System, VCS)은 바로 이러한 혼돈과 불안을 해결하기 위해 탄생한 시스템이다.

 

★ 버전 관리 시스템의 핵심적인 이

• 변경 이력 추적: 파일의 수정 내역을 상세히 기록하여 프로젝트의 발전 과정을 투명하게 볼 수 있다.
• 손쉬운 복원: 실수로 파일을 잘못 수정하거나 삭제해도 특정 버전으로 간단히 되돌릴 수 있어 작업의 안정성이 크게 올라간다.
• 버전 비교: 과거의 특정 버전과 현재 상태를 비교하여 어떤 코드가 변경되었는지 명확하게 확인할 수 있다.
• 효율적인 협업: VCS의 가장 큰 강점은 협업 환경에서 드러난다. 여러 사람이 동시에 한 프로젝트를 작업할 때, 누가 무엇을 수정했는지 추跡하고 각자의 작업물을 충돌 없이 병합(merge)하도록 도와준다. 이를 통해 서로의 작업을 덮어쓸 위험을 막고 팀의 생산성을 극대화한다.

 

파일명에 의존하는 주먹구구식 관리는 실수를 유발하고 협업을 어렵게 만든다. 반면, Git을 사용하면 프로젝트의 모든 변경 사항을 체계적으로 추적하고 팀원들과 안전하게 협업하는 전문가 수준의 관리 환경을 구축할 수 있다.

 

 

 

 

Github

Git과 GitHub, 무엇이 다른가?
Git을 배우기 시작하면 항상 함께 등장하는 이름이 바로 GitHub(깃허브)이다.

둘은 이름이 비슷해 헷갈리기 쉽지만, 그 역할은 명확히 다르다.
Git이 내 컴퓨터에서 코드의 버전을 관리하는 '버전 관리 프로그램' 그 자체라면, 

GitHub는 Git으로 관리하는 프로젝트를 다른 사람과 공유하고 함께 작업할 수 있도록 도와주는 웹 기반의 협업 플랫폼'이다. 

좀 더 쉽게 비유해 보자.

Git이 글을 쓰고 수정하며 버전을 관리하는 '워드 프로세서(MS Word)'라면,
GitHub는 그 워드 파일을 올려두고 다른 사람과 함께 편집하며 댓글을 다는 '구글 드라이브'와 같다.

GitHub의 핵심 역할: 원격 저장소와 협업
GitHub는 Git 사용자에게 다음과 같은 핵심적인 환경을 제공한다.

1. 원격 저장소 (Remote Repository)
로컬(내 컴퓨터)의 Git 프로젝트를 GitHub에 올려 온라인 저장소로 사용한다. 

이를 통해 코드를 안전하게 백업하고, 어디서든 접근하며, 팀원들과 공유하는 중심점 역할을 한다.

2. 강력한 협업 기능
GitHub의 핵심으로, 팀 프로젝트의 효율을 극대화한다.
코드 리뷰 (Pull Request): 변경된 코드를 동료와 함께 검토하며 코드의 품질을 높이고 실수를 방지한다.
이슈 관리 (Issues): 프로젝트의 할 일, 버그 등을 체계적으로 등록하고 논의하며 관리한다.

3. 개발자 포트폴리오
자신이 작업한 프로젝트를 공개하여 개발 실력을 증명하고, 다른 개발자들과 교류하는 소셜 플랫폼으로도 활용된다.
한마디로, Git이 버전 관리 '엔진'이라면 GitHub는 그 엔진을 기반으로 온라인에서 협업하고 프로젝트를 관리하는 '웹 플랫폼'이다. 둘은 함께 사용될 때 가장 강력한 시너지를 낸다.

 

 

 

 

Git Repository (이력을 관리하는 저장소)

 

Git 리포지토리는 프로젝트의 파일과 모든 변경 이력을 담고 있는 '버전 관리 저장소'이다.

이 저장소는 파일의 아주 작은 변화까지 모두 기록하고 버전별로 관리한다.

덕분에 다음과 같은 핵심 이점을 얻을 수 있다.

• 변경 이력 추적: 파일의 수정 내역을 체계적으로 관리하여 협업 시 작업 내용을 효과적으로 추적한다.
• 시점 복원: 필요할 때 원하는 버전(특정 시점)의 상태로 프로젝트를 손쉽게 되돌릴 수 있다.

Git Repository의 두 종류 저장소

• 로컬 리포지토리 (Local Repository)
  • 내 PC에 저장되는 개인 전용 저장소.
  • 모든 버전 관리(커밋 등)는 이곳에서 이루어진다.
• 원격 리포지토리 (Remote Repository)
  • GitHub 등 원격 서버에 있는 공용 저장소.
  • 팀원들과 코드를 공유하고 협업하기 위한 공간이다.

모든 작업은 개인의 로컬 리포지토리에서 진행되지만, 다른 사람과 그 결과를 공유하려면 반드시 원격 리포지토리를 이용해야 한다.

 

원격 리포지토리와의 소통: Push와 Pull
로컬 리포지토리와 원격 리포지토리는 Push와 Pull이라는 명령어를 통해 데이터를 주고받는다.
＊ Push: 로컬에서 작업한 내용을 원격 리포지토리로 업로드하여 공유하는 것.
＊ Pull: 원격 리포지토리의 최신 변경 사항을 로컬 리포지토리로 가져와 갱신하는 것.

 

 

 

 

Git의 핵십 작업 흐름 - 스테이지와 커밋 이해

Git으로 버전을 만드는 과정은 '작업 트리 → 스테이지 → 리포지토리' 라는 3단계를 거친다.

이 중 스테이지와 리포지토리는 눈에 보이지 않으며, Git이 관리하는 .git 폴더 안에 존재하는 개념적인 공간이다.

이 과정을 '이삿짐 싸기' 에 비유하면 쉽게 이해할 수 있다.

1. 작업 트리 (Working Tree)
   • '집 안' 에 해당한다. 이곳에서 우리는 파일을 수정하거나 새로 만드는 등 자유롭게 작업을 한다.
   • 하지만 집 안에 물건이 있다고 해서 모두 이삿짐은 아니다.
2. 스테이지 (Stage)
   • '이삿짐 박스' 와 같다. 집 안에 있는 물건(변경된 파일) 중, 이번에 이삿짐으로 보낼 것들만 골라 담는 공간이다.
   • git add 명령어는 이 박스에 물건을 담는 행위다. 버전을 만들 파일만 선별적으로 추가할 수 있다.
3. 리포지토리 (Repository)
   • '창고' 에 해당한다. 박스에 담긴 짐(스테이지의 파일들)을 git commit 명령어로 확정하면,
     하나의 버전(이삿짐 묶음)으로 만들어져 창고에 영구적으로 보관된다.
   • '커밋한다'는 것은 바로 이 박스를 테이프로 봉인하여 창고로 보내는 행위와 같다.

 

 

 

독립적인 작업 공간 - 브랜치(Branch)

브랜치(Branch)는 기존 코드의 안정적인 흐름(main 브랜치)에 영향을 주지 않고,

새로운 기능을 개발하거나 버그를 수정할 수 있도록 독립적인 작업 공간을 만드는 기능이다.

마치 나무의 원줄기에서 새로운 가지(Branch)가 뻗어 나가는 것과 같다.

 

브랜치가 왜 필요할까?

• 안전한 코드 분리: 메인 코드에 직접적인 영향을 주지 않고 신기능을 마음껏 테스트하고 개발할 수 있다.
  문제가 생겨도 해당 브랜치만 삭제하면 그만이다.
• 여러 작업의 동시 진행: '로그인 기능 브랜치', '결제 기능 브랜치'처럼
  기능별로 브랜치를 만들어 각기 다른 작업을 동시에 독립적으로 진행할 수 있다.
• 체계적인 팀 협업: 각 팀원이 자신의 브랜치에서 맡은 기능을 개발한 뒤,
  작업이 완료되면 병합(Merge)을 통해 안전하게 메인 코드에 합칠 수 있어 효율적인 협업이 가능하다.

 

 

---