Git과 GitHub

Fox·2024년 3월 20일
gitgithub
0
post-thumbnail

Git과 GitHub

Git

정의

Git은 분산 버전 관리 시스템(DVCS)으로, 여러 개발자가 공동으로 작업하는 프로젝트에서 코드의 버전을 관리하고 변경 이력을 추적할 수 있도록 설계된 도구이다.
로컬 시스템에 설치되어 작업을 수행한다.

특징

브랜치(Branch): 
Git의 가장 강력한 기능 중 하나로, 독립적인 작업 영역을 만들어 새로운 아이디어를 시험하거나, 다른 작업을 병행할 수 있게 한다.
이는 코드의 주된 흐름을 방해하지 않으면서 변경사항을 실험해 볼 수 있게 해준다.

단점: 
Git 자체는 로컬에서 운영되는 시스템이기 때문에, 협업 과정에서 실시간으로 다른 개발자와 작업 내용을 공유하기 위해서는 추가적인 도구나 플랫폼이 필요하다.

GitHub

정의

GitHub는 Git의 클라우드 기반 호스팅 서비스로, Git 저장소를 온라인에 보관하고 관리할 수 있게 해준다.
이는 프로젝트의 공유, 버전 관리, 협업을 비롯한 다양한 기능을 제공한다.

특징

확장 기능: 
GitHub는 사용자 친화적인 인터페이스를 제공하며, GitHub Marketplace를 통해 다양한 통합 도구와 서비스를 이용할 수 있다.
이러한 도구들은 프로젝트 관리, 코드 리뷰, CI/CD(지속적 통합 및 배포) 등을 용이하게 한다.

협업: 
GitHub는 다양한 협업 도구를 제공하여 팀원 간의 소통과 협력을 증진시킨다.
브랜치, 풀 리퀘스트, 이슈 트래커 등을 통해 개발자들이 효과적으로 협업할 수 있다.

다른 Git 저장소 호스팅 서비스로는 여러 가지가 있다: GitLab, BitBucket, SourceForge

Repository

정의

레파지토리(Repository)는 코드, 문서, 그리고 해당 프로젝트와 관련된 다양한 파일들을 저장하는 공간이다.
Git에서는 변경사항의 이력을 추적하며 협업을 위한 기반을 제공한다.

종류

원격 저장소(Remote Repository): 
일반적으로 GitHub와 같은 서버에 위치한 저장소로, 프로젝트의 중앙 집중식 저장소 역할을 한다.
여기에 코드의 최신 버전이 저장되며, 협업을 위해 접근 가능하다.

로컬 저장소(Local Repository): 
개발자의 개인 컴퓨터 내에 위치한 저장소로, 개인 작업 공간이다.
여기서 코드를 수정하고, 커밋을 통해 변경사항을 기록한다.

Git의 주요 명령어

  • Clone: 원격 저장소의 내용을 로컬 컴퓨터로 복제한다. 이를 통해 로컬에서 작업을 시작할 수 있다.
  • Commit: 로컬 저장소의 변경 사항을 기록한다. 각 커밋은 이전 상태로 돌아갈 수 있는 체크포인트 역할을 하며, 커밋 시에는 변경 사항에 대한 설명을 포함하는 메시지를 함께 기록한다.
  • Push: 로컬 저장소의 변경 사항을 원격 저장소에 업로드한다. 이렇게 하면 다른 사람들도 변경 사항을 볼 수 있다.
  • Pull: 원격 저장소의 최신 변경 사항을 로컬 저장소로 가져온다. 이는 원격 저장소의 변경 사항을 로컬에 동기화하는 과정이다.
  • Fetch: 원격 저장소의 최신 변경 사항을 로컬로 가져오지만, 바로 병합하지는 않는다. 이후 병합을 위해 merge 명령어를 사용할 수 있다.
  • Merge: 두 가지 버전의 변경 사항을 하나로 병합한다. 주로 다른 브랜치의 변경 사항을 현재 브랜치로 병합할 때 사용한다.
  • Branch: 작업을 분리하여 관리하기 위한 브랜치를 생성, 삭제, 목록 확인 등을 할 수 있다. 각 브랜치는 다른 브랜치의 영향을 받지 않으면서 독립적으로 작업을 진행할 수 있다.
  • Checkout: 다른 브랜치로 전환하거나, 특정 버전의 파일을 체크아웃하여 작업할 수 있다. 이를 통해 과거의 특정 시점으로 돌아가거나 다른 브랜치의 작업을 시작할 수 있다.
  • Status: 현재 작업 디렉토리와 인덱스의 상태를 확인할 수 있다. 수정된 파일, 커밋되지 않은 변경 사항 등을 확인할 수 있다.
  • Log: 커밋 히스토리를 확인할 수 있다. 커밋의 ID, 저자, 날짜, 커밋 메시지 등의 정보를 볼 수 있다.
  • Diff: 변경 사항을 비교할 수 있다. 워킹 디렉토리와 인덱스, 또는 두 커밋 간의 차이점을 확인할 수 있다.

master 브랜치

저장소를 처음 만들면, Git은 바로 ‘master’라는 이름의 브랜치를 만들어 준다.
이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 ‘master’ 라는 이름의 브랜치를 통해 처리할 수 있는 일이 된다.

‘master’가 아닌 또 다른 새로운 브랜치를 만들어서 ‘이제부터 이 브랜치를 사용할거야!’라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 ‘master’ 브랜치에서 이루어 진다.

branch

소프트웨어를 개발할 때에 개발자들은 동일한 소스코드를 함께 공유하고 다루게 된다.

이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 ‘브랜치(Branch)’ 이다. 
이렇게 분리된 작업 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있다.

또한 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있다.

아래 그림을 보면, 브랜치를 사용하여 동시에 여러 작업을 진행할 때의 작업 흐름을 한눈에 파악할 수 있다.

여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만든다.
그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용한다.
이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 된다.
이러한 방식으로 작업할 경우 ‘작업 단위’, 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워진다.

issue

이슈(Issue)란 프로젝트에서 작업해야할 단위라고 할 수 있다.

개발해야하는 기능 발생, 수정해야할 사항 버그 발생, 리팩터링 해야하는 코드 발생 등 프로젝트에서 발생되는 작업들을 이슈로 생성하여 관리한다.

이슈를 생성하여 관리하면, 이슈에 대한 커밋 내역들을 하나의 이슈 페이지에서 관리가 가능하며
어떤 작업을 해야하는 지, 누가 해야하는 지, 얼마나 진행됐는 지 등에 대한 정보를 한 곳에 묶어서 관리할 수 있다.
또한 코멘트 기능을 통해 서로의 의견을 주고 받을 수 있어 작업을 단위로 구분하여 협업 및 관리하기 편하도록 도와준다.

추가적으로 이슈 생성 시, 이슈번호가 부여되는데 이를 통해 이슈 관리가 가능하다.

Issue의 Flow

  • A라는 기능을 개발해야하는 상황이 발생
  • A기능 개발에 대한 Issue를 생성
  • develop 브랜치에서 A기능 개발에 대한 Branch 분기
  • 생성한 Branch에서 A기능 개발 시작
    • 이때 커밋 메세지에 #이슈번호 를 붙여주면 해당 이슈 페이지에서 커밋 내역을 확인할 수 있다.

pull request

PR은 서로 다른 브랜치에서 변경 사항을 합병(Merge) 하기 위하여,
”내가 만든 코드를 가져가줘~!” 라는 요청을 의미한다.

즉 Pull(당기다) + Request(요청) → 가져달라고 요청 이라고 이해하면 된다.

보통 PR은 이슈 단위로 수행된다.

PR의 Flow

profile
Fox
주니어개발자 Fox 입니다 🦊
이전 포스트

CSRF와 XSS

다음 포스트

JavaScript

0개의 댓글