Git은 **분산 버전 관리 시스템 (VCS)**로, 프로젝트 파일의 변경 사항을 추적하는 시스템이다.
이를 통해 개발자들은 프로젝트의 변경 사항을 기록하고, 특정 시점의 버전으로 언제든 돌아갈 수 있다.
많은 사람들이 효율적으로 함께 작업하고, 프로젝트를 중심으로 협업할 때 사용할 수 있다.
Git repository란 Git으로 관리하는 프로젝트 저장소이다 (폴더라고 생각할 수도 있다).
Git repository에는 다음과 같이 크게 두 가지 종류가 있다.
Git에서 commit이란, 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷으로 생각할 수 있다.
쉽게 말해, 현재 버전의 코드를 커밋에 저장한다고 생각하면 된다. 커밋 히스토리에 필요한 만큼 커밋을 생성 할 수 있고, 커밋 앞뒤로 이동하여 프로젝트 코드의 다른 변경사항을 확인할 수 있다.
*** 코드를 커밋하려면 우선 코드를 staging area
에 추가해야 한다.**
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념이다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행 할 수 있다.
팀 안에서 동시의 작업을 진행 할 때, 다른 사람의 작업에 영향을 주거나 받지 않도록, 메인 브랜치에서 자신의 작업 전용 브랜치를 만든다. 그리고 각자 작업이 마무리되면, 자신의 브랜치의 변경사항을 메인 브랜치에 적용한다.
GitHub은 Git repository를 위한 호스팅 플랫폼이다. GitHub나 기타 유사 플랫폼 없이도 Git을 사용할 수는 있지만 다른 개발자와 같은 프로젝트를 두고 협업하거나 내 코드를 공유하기는 어렵다.
Pull Request는 말 그대로 자신이 작업한 브랜치 작업 내용을 master 브랜치에 반영해달라는 요청이다. 이렇게 함으로써 프로젝트 오너 또는 팀 리더에게 리뷰를 받을 수 있게 되고, 그 과정에서 버그나 컨플릭트가 있다면 다시 수정해서 요청하게 되고, 병합되기에 아무런 문제가 없다면 머지 권한이 있는 개발자가 병합을 진행한다.
Merge가 되기 전 항상 **conflicts(충돌)**가 발생할 수 있다. Conflict는 어떤 파일의 변경 사항이 기준이 되는 master 브랜치의 파일과 겹쳐, Git에서 어떤 버전의 코드를 선택해야 할지 모를 때 발생하는 것이다.
충돌이 발생한다면, 개발자가 직접 코드를 비교해 충돌을 해결하고 merge를 마무리 해야한다.
Git Flow란 어떤 기능이 아니라 Vincent Drissen이 시작한 Git 사용 방법론이다.
Git Flow는 총 5가지의 브랜치를 사용해서 운영 한다.
master
: 기준이 되는 브랜치로 제품을 배포하는 브랜치이다.develop
: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 병합(merge)한다.feature
: 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합친다.release
: 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(Quality Assurance, 품질 검사)를 하기위한 브랜치이다.hotfix
: master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치이다.Git Rebase는 일련의 커밋들을 새로운 베이스 커밋으로 옮기거나 합치는 과정이다.
이 두 명령 다 한 브랜치에서 다른 브랜치로, 변경 사항들을 통합하기위해 디자인 됬다.
즉, 두 명령은 비슷하지만 그저 다른 방법으로 사용되는 것이다.
Squash와 Reward는 커밋 히스토리를 조정하는 기능이다.
사소한 커밋들이 여러번 있다면, 이 커밋을 큰 하나의 커밋으로 변경할 수 있다.
squash
는 커밋을 합친다.reward
는 커밋은 남겨두고 메시지만 수정한다.