면접 준비 | Git & GitHub

jacoblee19·2021년 2월 17일
2

TIL x Wecode

목록 보기
8/9
post-thumbnail

Git & GitHub

Git이란?

Git은 **분산 버전 관리 시스템 (VCS)**로, 프로젝트 파일의 변경 사항을 추적하는 시스템이다.
이를 통해 개발자들은 프로젝트의 변경 사항을 기록하고, 특정 시점의 버전으로 언제든 돌아갈 수 있다.
많은 사람들이 효율적으로 함께 작업하고, 프로젝트를 중심으로 협업할 때 사용할 수 있다.

Repository란?

Git repository란 Git으로 관리하는 프로젝트 저장소이다 (폴더라고 생각할 수도 있다).

Git repository에는 다음과 같이 크게 두 가지 종류가 있다.

  • Local respository - 자신의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소
  • Remote repository - 로컬 repository와는 반대로, 내 컴퓨터가 아닌 외부 (일반적으로 원격 서버) 버전의 프로젝트 저장소이다. 팀 협업시에 많이 사용하며, 프로젝트 코드를 공유할 수 있고, 다른 사람의 코드도 확인할 수 있다. 또, 로컬 버전의 프로젝트와 병합하고, 변경 사항을 적용할 수 있는 곳이다.

Commit이란?

Git에서 commit이란, 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷으로 생각할 수 있다.
쉽게 말해, 현재 버전의 코드를 커밋에 저장한다고 생각하면 된다. 커밋 히스토리에 필요한 만큼 커밋을 생성 할 수 있고, 커밋 앞뒤로 이동하여 프로젝트 코드의 다른 변경사항을 확인할 수 있다.
*** 코드를 커밋하려면 우선 코드를 staging area에 추가해야 한다.**

Branch란?

브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념이다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행 할 수 있다.

팀 안에서 동시의 작업을 진행 할 때, 다른 사람의 작업에 영향을 주거나 받지 않도록, 메인 브랜치에서 자신의 작업 전용 브랜치를 만든다. 그리고 각자 작업이 마무리되면, 자신의 브랜치의 변경사항을 메인 브랜치에 적용한다.

  • 보통 현업에서는 development 브랜치를 만들고, 또 그 안에서 브랜치를 만들어 각자 작업물을 development 브랜치에 병합한다. 그리고 테스트를 거쳐서 문제가 없으면 최종적으로 배포 단계에서 master 브랜치에 병합한다.

GitHub란?

GitHub은 Git repository를 위한 호스팅 플랫폼이다. GitHub나 기타 유사 플랫폼 없이도 Git을 사용할 수는 있지만 다른 개발자와 같은 프로젝트를 두고 협업하거나 내 코드를 공유하기는 어렵다.

Git vs. GitHub

  • Git은 버전 관리 시스템으로, 시간이 지남에 따라 파일의 변경 사항을 추적하는 도구이다.
  • GitHub은 Git을 사용하는 프로젝트를 위한 호스팅 서비스이다.

Pull Request(PR)란?

Pull Request는 말 그대로 자신이 작업한 브랜치 작업 내용을 master 브랜치에 반영해달라는 요청이다. 이렇게 함으로써 프로젝트 오너 또는 팀 리더에게 리뷰를 받을 수 있게 되고, 그 과정에서 버그나 컨플릭트가 있다면 다시 수정해서 요청하게 되고, 병합되기에 아무런 문제가 없다면 머지 권한이 있는 개발자가 병합을 진행한다.

Conflicts란?

Merge가 되기 전 항상 **conflicts(충돌)**가 발생할 수 있다. Conflict는 어떤 파일의 변경 사항이 기준이 되는 master 브랜치의 파일과 겹쳐, Git에서 어떤 버전의 코드를 선택해야 할지 모를 때 발생하는 것이다.
충돌이 발생한다면, 개발자가 직접 코드를 비교해 충돌을 해결하고 merge를 마무리 해야한다.

Git Flow란?

Git Flow란 어떤 기능이 아니라 Vincent Drissen이 시작한 Git 사용 방법론이다.

Git Flow는 총 5가지의 브랜치를 사용해서 운영 한다.

  • master: 기준이 되는 브랜치로 제품을 배포하는 브랜치이다.
  • develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 병합(merge)한다.
  • feature: 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합친다.
  • release: 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(Quality Assurance, 품질 검사)를 하기위한 브랜치이다.
  • hotfix: master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치이다.

Git Rebase란?

Git Rebase는 일련의 커밋들을 새로운 베이스 커밋으로 옮기거나 합치는 과정이다.

  • rebase는 이름에서 보이는 것과 같이 base를 re, 즉 base를 재설정 해주는 것이다.
  • base가 옮겨지니 커밋도 변경되어 새로운 베이스를 기준으로 정렬된다.
  • rebase를 해서 git history를 정리하는 것이 보기도 편해지기도 하지만, 상대 개발자를 위한 배려이기도 하다.

Git merge vs. rebase

이 두 명령 다 한 브랜치에서 다른 브랜치로, 변경 사항들을 통합하기위해 디자인 됬다.
즉, 두 명령은 비슷하지만 그저 다른 방법으로 사용되는 것이다.

Squash vs. Reward

SquashReward커밋 히스토리를 조정하는 기능이다.
사소한 커밋들이 여러번 있다면, 이 커밋을 큰 하나의 커밋으로 변경할 수 있다.

  • squash는 커밋을 합친다.
  • reward는 커밋은 남겨두고 메시지만 수정한다.
profile
Back-end Developer 🙇‍♂️ 💻 🙆‍♂️

0개의 댓글