Git
개요
버전 관리(Source Code 파일의 버전)는 이전의 데이터를 백업해둔다는 의미에서(이외에도 많이 있지만), 프로젝트를 진행하는데에 있어서 필수적인 요소 중 하나이다. 가장 쉬운 버전 관리는 파일로 각각의 버전을 관리하는 것이다. 하지만 그렇게 되면 프로젝트가 진행되고, 파일의 갯수가 많아지면서 여러가지 문제들이 발생할 여지가 있다.
Git은 이러한 버전 관리를 제공해주는 시스템이다. 그리고 Github은 Git을 통해 저장하는 저장소이다. Git을 사용하게 되면, 코드 변경 사항의 내역을 기록 및 관리할 수 있다. 그리고 필요할 경우, 이전 상태로 Rollback할 수도 있다.
Branch를 통해 여러 사람이 단일 프로젝트를 할 때도 서로 방해 받지 않고 개발을 할 수 있기 때문에, 팀 단위로 개발할 때 체계적이고 효과적으로 협업을 할 수 있다.
기초적인 흐름은 이러하다 Modified => Staged(Git added) => Committed(History에 저장)
git 이외의 버전관리 시스템으로는 bitbucket과 같은 것들이 있다. git은 버전관리 시스템 중 가장 규모가 큰 편이다.
그리고 git은 무료 Private Repo를 지원하지 않는 반면, Bitbucket은 무료로 Private Repo를 지원한다(Private Collaborator는 비용을 지불해야 한다).
git은 사용자가 굉장히 많고, 기본적으로 Repository의 갯수에 제한이 없다보니 Open Source에 대한 Online Community가 장점이다.
기본적인 명령어
git init: local에 새로운 repository를 만든다.
git clone: local에 repository를 복사한다.
git add: 상태에 1개 혹은 그 이상의 파일을 추가한다.
git commit: 상태를 commit한다. repository에 접근하기 바로 전 단계
git stash: 임시 저장 후, 이전 상태로 돌아간다.
git push { branch }: branch에 commit한 사항을 업로드 한다.
git status: 현재의 상태
git remote add origin: local에 있는 repository를 서버에 연결할 때 사용한다.
git branch: 해당 repository의 branch 리스트를 보여준다.
git checkout { branchname }: 해당 branch로 이동한다.
git log: commit한 기록들을 보여준다.분산 관리 시스템
CVS(1986): Concurrent Versions Systems 동시 버전 시스템
CVS는 클라이언트-서버 구조로 이루어졌다.
서버는 프로젝트의 현재 버전과 변화를 저장한다.
클라이언트는 서버에 접속해서 프로젝트의 복사본을 얻을 수 있고, 작업한 뒤에 바뀐 내용을 Check In 한다.
서버는 달라진 내용을 합치기 시작한다. 만약 실패했다면 클라이언트에게 충돌을 알린다.
클라이언트는 충돌을 해결한다.
모든 파일이 합쳐지고 자동적으로 버전이 증가한다.
CVS의 한계
- CVS 저장소의 파일들의 이름 변경이 불가능하다. 만약 바꾸고 싶다면 삭제하고 다시 추가해야 한다.
- CVS 프로토콜은 디렉토리의 이동이나 이름 변경을 허용하지 않는다.
Subversion(2000): CVS의 한계를 극복하기 위해 만들어진 자유 소프트웨어 버전 관리 시스템
콜랩넷에서 CVS와 비슷하지만 기존에 존재하지 않던 기능을 추가하고, 버그를 수정한 버전 관리 시스템을 만들다가 2000년에 개설했다.
Automatical Writing을 지원하기 때문에 갑작스러운 중단에 의한 저장소 내의 불일치 혹은 손상을 피할 수 있다.
이름을 바꾸거나, 복사하거나, 파일을 지워도 계정 기록을 유지한다.
이진 파일의 경우, 변경 사항이 있을 때 차이점만 저장하기 때문에 효율적으로 저장소를 사용할 수 있다.
중앙 집중식 저장소
중앙 집중식 저장소는 하나의 중앙 저장소(서버)가 있고, 이 저장소가 모든 데이터와 변경 사항을 저장한다.
개발자는 저장소의 최신 버전을 복사해서 갖고 있어야 하며, 작업한 뒤에는 변경된 부분을 중앙 저장소에 전송한다.
그렇기 때문에 개발자는 최신 버전의 코드만 가지고 있다는 단점, 변경 이력을 확인하려면 저장소에 정보를 요청해야 한다는 단점이 있다.
저장소에 정보를 요청한다는 것은 네트워크 상에서 원격 저장소로 접근해야 한다는 것을 의미하고, 이는 인터넷에 연결할 수 없는 환경에서 매우 큰 단점으로 작용한다.
분산 버전 관리 시스템
모든 개발자가 각각 자신만의 중앙 저장소를 가진다.
프로젝트의 전체 이력을 자신의 중앙 저장소에 저장한다.
변경 사항을 저장할 때는 네트워크에 연결할 필요 없이 자신의 중앙 저장소에 기록한다.
원격 중앙 저장소(중심 서버)에 동기화를 해야 할 때는 자신의 작업물을 원격 중앙 저장소에 전송한다.
git을 왜 쓸까..?
git은 분산 버전 관리 시스템을 사용한다.
중앙 집중식 저장소보다는 분산 버전 관리 시스템이 오픈 소스에 조금 더 적합하다.
왜냐하면 모든 사람이 하나의 소스 코드를 기반으로 동등한 레벨에서 작업이 가능하기 때문이다.
물론 실제 서비스를 제공하는 소스 코드일 경우, 모든 사람이 협의한 하나의 소스 코드의 저장소만을 실질적으로 배포하여 사용하겠지만 한 명의 개발자가 fork한 repository도 개념상에서 동등한 레벨에 있다.
Git Rebase, Git Flow
Git은 기본적으로 Commit을 한 시점을 기준으로 다른 branch에 Merge를 하게 된다. 그렇기 때문에 만약 동시다발적으로 개발을 할 경우, 기능 단위로 Revert를 하기 어렵게 된다.
따라서 각자의 작업량을 한데 묶은 뒤, 최신 Branch에 push하여 Merge를 진행하는 것이 바로 Rebase의 기능이다. 다시 말해, 기능 단위의 Branch에 Commit들을 합친 뒤 최신 Branch로 Merge하는 것을 말한다.
그렇다면 Git Flow는 무엇일까. git flow에는 총 5가지의 branch가 있다.
master | develop | feature | release | hotfix
우선 master는 배포의 기준이 되는 branch이다. 가장 검증이 되어있어야하며, 가장 안전한 branch이다.
develop은 개발의 기준이 되는 branch이다. 새로운 기능들을 개발할 때, 기준이 되어 모든 기능들이 한데 모인 Branch이다.
feature는 실제 개발을 할 때, 기능 단위로 나눈 branch이다. 이를 통해, 개인 단위로 나누어 작업할 수 있기 때문에 서로 외부의 영향을 받지 않고 개발할 수 있다.
release는 배포를 앞둔 시점에서 실제 구동되는 서비스라고 가정하고 End-TO-End 테스트를 해볼 수 있는 branch이다.
만약 master에서 버그가 발견될 경우, hotfix를 통해 재빨리 수정할 수 있도록 한다. 그리고 수정이 완료되었다면, develop에도 merge해서 개발 시에 반영될 수 있도록 한다. 단, 버그가 너무 심각할 경우, master를 이전 버전으로 되돌리고, 버그를 수정한다.
