1. Git이란?
컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.
소프트웨어 개발에서 소스 코드 관리에 주로 사용되지만, 어떠한 집합의 파일의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다.
기하학적 불변 이론을 바탕으로 설계됐고, 분산 버전 관리 시스템으로서 빠른 수행 속도에 중점을 두고 있는 것이 특징이며,
데이터 무결성, 분산, 비선형 워크플로를 지원한다.
2. Git 개념
1) Repository(저장소)
레포지토리는 단어 뜻 그대로 파일 등이 저장되는 저장소로, 프로젝트 폴더를 말한다. 저장소의 종류는 2개이다.
- Remote Repository(원격 저장소) - 원격 서버에 저장된 저장소로, 여러 사람이 함께 공유한다.
- Local Repository(개인 저장소) - 우리가 직접 관리하는 저장소로, 내 pc에 저장되어 있다.
보통 레포지토리는 로컬에서 만들어서 원격에 업로드하거나, 원격에서 생성된 레포지토리를 로컬로 다운로드하는 방법으로 생성한다.
2) Commit
커밋은 프로젝트의 변경 이력을 말한다.
3) Stage
스테이지를 알기 전에 Index에 대한 개념을 우선 이해해야 한다. Index는 Commit을 통해 변경사항들이 반영되기 전 해당 변경사항의 이력들을 저장하는 공간이다. 따라서 우리가 특정 파일이나 코드를 변경 시 해당 이력은 Index에 기록된다. 이때, 이 기록되는 행위를 Stage 또는 Staging라고 한다. 따라서, 아래 그림과 같이 5개의 변경사항이 있을 시, 그중에서 원하는 변경 사항만 stage 하고 원하지 않은 변경 사항은 unstage 해주고 commit을 진행하면 된다.
쉽게 생각해서 커밋이 여러 변경사항들의 집합이라 하면, 스테이지는 그 변경사항 하나하나를 반영할지를 결정하는 것이라 볼 수 있다.
4) Branch
위 부분은 모두 개인이 로컬에서 개발하는 상황을 가정한 것이다. 이번엔 여러 사람과 협업하는 상황이라 가정해보면, 각 개발자들은 여러 커밋을 만들며 코드를 발전시키는데, 이때 누가 커밋을 추가했는지 구분이 가능해야 한다. 이때 사용되는 것이 바로 브랜치이다.
브랜치는 특정 커밋으로부터 분기되는 포인터를 말하는 것으로, 각 개발자들이 개발을 진행하고 있는 환경 또는 흐름을 말한다. 새로운 브랜치를 생성하더라도 기존의 마스터 브랜치는 그대로 남아있다.(아래 그림 참고)
물론, 나눈 브랜치에 또 세부 브랜치를 나눌 수도 있다.
⚠️ 브랜치 생성 개수는 제한이 없다.
5) Checkout
현재 위치한 브랜치에서 다른 브랜치로 이동하는 것을 체크 아웃이라 한다.(현재 위치한 커밋에서 다른 커밋으로 이동하는 것)
체크아웃을 통해 현재 커밋에서 같은 브랜치 내 다른 커밋으로 이동하거나, 다른 브랜치 내 커밋으로 이동할 수 있다.
그리고 체크아웃을 통해 수정 이전 시점으로 되돌아갈 수도 있고, 다른 사람의 브랜치로 전환해 다른 개발자들의 코드 진행 상황을 확인해 볼 수 있다.
6) Merge
merge는 나뉘었던 브랜치를 하나의 브랜치로 합치는 것을 말한다. (아래 사진 참고)(오류가 많이 발생하는 구간인 만큼 주의하기!)
Merge 진행 시 현재 브랜치를 브랜치가 합쳐지는 기존 마스터 브랜치로 전환한 후 수정된 브랜치를 Merge 해야 오류가 발생하지 않는다.
여러 개의 브랜치들을 한꺼번에 Merge 할 때도 마찬가지로 차례차례 기존 브랜치 상태에서 Merge를 진행해야 한다.
Merge는 두 가지 종류가 있다.
- fast-forward: 기본 merge 방식으로, 서로 다른 두 브랜치를 충돌 없이 자동 merge 시키는 병합
- non fast-forward: fast-forward 과정에서 일부 문법으로 인해 충돌(conflict)이 발생하면 병합에 실패하는 경우가 발생하는데, 이때 해당 충돌 기록을 살피며 일일이 해당 코드를 수정한 뒤 merge를 이어서 진행하며 성공적으로 브랜치를 병합시키는 경우가 non fast-forward에 해당한다. 이 과정에서 코드의 수정이 이루어졌으니 새로운 커밋이 생성된다.
7) Clone
클론은 원격 저장소에서 특정 프로젝트를 통째로 내 로컬 저장소에 다운로드하는 것을 말한다.
8) Push
푸시는 현재 내 로컬에서 작업한 변경 사항들을 원격 저장소에 반영하는 것을 말한다. 작업 완료할 때마다 원격 저장소에 push 해야 다른 사람들이 내 코드를 확인할 수 있다.
9) Pull
풀은 원격 저장소에서 변경된 사항들을 내 로컬 저장소에 반영하는 것을 말한다. push와 반대되는 개념으로, 다른 사람이 push를 해서 원격 저장소에 코드를 업데이트하면, 해당 코드를 pull 하여 로컬의 코드를 업데이트한다. 이때, 기존의 코드와 내 코드가 다른 경우 merge를 진행해 코드를 합치게 된다.(굳이 merge를 해주지 않아도 상관없다.)
⚠️Clone은 프로젝트를 처음 불러올 때, 프로젝트 전체를 다운로드하는 것이고, Pull은 해당 프로젝트에서 변경된 사항들을 업데이트하는 것.
3. Git Flow
Git Flow란 저장소를 보다 높은 수준으로 관리하기 위한 방법론이다. 프로젝트의 규모가 커지면, 많은 인원들이 코드에 동시 접근하면서 문제가 발생하는 것을 해결하기 위해서는 Git Flow를 잘 알고 있어야 한다.
Git-flow는 총 5가지의 브랜치를 사용해서 운영한다.
- master: 실제로 클라이언트에서 이용하는 최종 형태의 메인 브랜치 (메인 배포판)
- develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합친(merge)다. / 현재 개발이 진행 중인 메인 브랜치. master 브랜치와 마찬가지로 추가적으로 생성 또는 삭제되지 않는 브랜치이다. (메인 개발)
- feature: 새로운 기능을 추가하기 위해 사용되는 브랜치로, 특정 기능의 개발이 필요할 때 develop 브랜치에서 파생되며, 기능 개발이 완료되면 Develop 브랜치로 병합된다. 가장 많이 생성되었다 삭제되는 브랜치이다. (추가 기능 개발)
- release: 실제로 프로젝트를 배포하기 위한 브랜치이다. 이 브랜치는 지금까지 개발한 기능들이 있는 develop 브랜치에서 파생되어, 각종 오류 사항이나 문제들을 검토 및 수정하는 일종의 테스트 서버로 볼 수 있다. 수정이 완료되면 release 브랜치는 develop 브랜치와 master 브랜치로 병합된다. (배포 준비, 오류 확인)
- hotfix: 배포된 master 브랜치에서 예상치 못한 오류가 발생했을 때 급하게 develop, feature 브랜치를 거치지 않고 오류를 수정하는 단계이다. 수정이 완료되면 develop와 master 브랜치로 병합된다. (긴급 오류 수정)
즉, master와 develop가 중요한 메인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보면 된다.
Git-Flow 설명 이미지(해설)
1. 일단 master 브랜치에서 시작한다.
2. 동일한 브랜치를 develop에도 생성한다. 개발자들은 이 develop 브랜치에서 개발을 진행한다.
3. 개발 진행 중 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현한다.
4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합친다.(Merge)
5. 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만든다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스한다.
6. 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보낸다. master브랜치에서 버전 추가를 위해 태그를 하나 생성하고 배포한다.
7. 배포했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포한다.
3. Git-Flow 진행
react나 bootstrap같이 규모가 있는 개발을 할 경우 브랜치보다는 Fork와 Pull requests를 활용하여 구현한다.
Fork는 브랜치와 비슷하지만 프로젝트를 통째로 외부로 복제해 개발하는 방식이다. 그렇게 개발해서 브랜치처럼 머지(Merge)를 바로 하는 것이 아니라 Pull requests로 원 프로젝트 관리자에게 머지 요청을 보내면 원 프로젝트 관리자가 Pull requests 된 코드를 보고 적절하다 싶으면 그때서야 그 기능을 붙이는 식으로 개발한다.
4. Git 자주 사용하는 용어 정리
· git init
-. git 폴더를 생성한다.
- .git 폴더가 있어야 파일을 추적할 수 있으며, Git과 관련된 작업을 할 수 있다.
· git add
- working directory의 변경된 작업 파일을 staging area로 추가시켜준다.
·git commit
- staging area의 내용을 local repository에 확정 짓는다.
·git push
- local repository의 내용을 remote repository로 업로드한다.
·git pull
- local repository의 내용을 remote repository에서 가져온다.
·git clone
-.git을 포함한 remote repository의 파일들을 local repository에 복사한다.
- 깃 헙에서 zip 파일로 받으면 .git 폴더가 없다는 것이 명령어와의 차이점이다.
(협업 - 병합)
·git branch
- 독립된 working directory를 의미한다.
- 브랜치를 통해 프로젝트 참여자마다 브랜치를 가져서 독립된 작업 공간을 갖는다.
- 테스트 및 백업 용도로 사용할 수도 있다.
·head
- 포인터를 의미하며, 지금 작업하고 있는 branch를 가리킨다.
·merge
- 2개의 branch에서 작업한 다른 내용을 하나로 합치는 것을 말하며, 현재 브랜치를 기준으로 병합된다.
- 만약 두 branch가 같은 파일의 같은 곳을 수정했다면, 충돌(merge conflict)이 발생해서 이를 해결해야 한다.
- 해당 이슈의 관계자들이 상의하여 수동으로 충돌을 해결.
- 충돌 이슈가 발생하지 않으려면 작업 내용이 겹치지 않도록 주의해서 분리시키는 것이 중요.
4. Github란?
Git이 프로그램이라면 GitHub는 파일의 버전 관리를 다른 사람들이 볼 수 있게 정보 교환이 이루어지는 일종의 서버(홈페이지)라고 볼 수 있다.
협업을 하고 소스에 대한 이력관리를 하고 소셜 코딩을 할 수 있다.
다른 사람들이 개발한 코드를 볼 수 있고, 진행되고 있는 프로젝트에 함께 참여하며 수정 및 보완 작업을 통해 협업할 수 있다.(위에 설명된 fork, pull, request, merge 등을 통해)
댓글