업데이트:

2 분 소요

개요

모든 분야를 능통하게 잘 알아서 어떤 프로그램을 만들어내고, 배포하고 업데이트 등의 관리를 잘 할수 있다면, 상관없다. 더 좋은 형상관리도구가 나오지 않는 이상 Git은 쓰게 될 것 이다.

먼저 Git에 대해 정리하기 전에 형상관리가 무엇인지 정리해본다.

형상관리란

소프트웨어 구성 관리(영어: Software Configuration Management) 또는 형상 관리는 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다.
출처 : Wikepedia

사전적 정의는 이렇다.
코드에서 변경점이 있어서 수정을 해야할 때 새로 작성한 코드가 다른 코드들에 어떤 예상치 못한 영향을 끼칠지 모른채 수정해야하거나, 여러 코드간에 어떤 코드가 더 좋을지 비교해야할 때 그 코드 들을 텍스트로 따로 보관하는 식이라면 꽤나 어지러울 것 이다.
이런 형상관리를 도와주는 것이 바로 형상관리 도구들이다.

형상 관리 도구의 종류

  • SVN
  • CVS
  • GIT

형상 관리 도구에는 크게 SVN, CVN, GIT, 외로는 Perforce, SourceSafe등이 있다.

여기서 왜 보편적으로 GIT을 사용할까?

본 포스팅은 형상 관리 도구들 보다는 Git에 대해 정리하는 포스팅이기 때문에 다른 형상관리도구들에 관해 간략하게만 설명한다.


cvs.png

먼저 CVS는 1990으로 비교적 오래전에 나왔다. 오래 사용된 만큼 안정적이지만 Commit 도중에 오류가 발생하면 롤백이 되지 않는 문제와 상대적으로 느리다는 문제점이 있었다.

SVN.png

그 후로 2000년에 나온 SVN은 CVS의 단점을 보완하기 나왔다. 최초 1회만 파일을 저장하고 이후로는 원본 파일과의 차이점을 저장한다.)
git의 다른 도구들과 가장 차이나는 특징이고, 이 특징은 git hub에 commit 하는 방식과 닮아있다고 생각했다.

show_diff.png github에서는 이전 커밋과의 차이점을 위와 같이 보여준다.

git.png

Git은 2005년에 나온 버전관리도구(형상관리 도구보다는 좁은 의미로 소스 코드만을 관리하는 도구이 대비되는 특징은 Branch. 로컬에 여러개의 독립성이 보장되는 branch를 허용하여 동시 다발적으로 협업이 가능하다는 것이다.

Branch ?

한 프로젝트를 맡은 다수의 개발자들은 하나의 소스 코드를 가지고 작업하게 되는데, 이 소스 코드를 개발자 마다의 각 독립된 로컬 저장소 안에서 마음대로 변경할 수 있게 해준다. (분기를 만들어 줄 수 있다!)

이 Branch를 통해서 작업하게 된다면 원본 소스코드의 유실 걱정없이 마음편하게 작업할 수 있을 것이다. :)

물론 CVS, SVN도 branch를 지원하지만, 속도와 편이한 버전관리등 협업의 관점으로 본다면
이 branch는 git을 쓰는 가장 큰 이유 일 것이다. (branch에 대해서는 아래에서 다시 설명할 것이다.)

Git 그리고 Github

Github는 git으로 관리하는 프로젝트를 호스팅하고, 시간과 공간의 제약 없이 협업할 수 있는 온라인 서비스이다. 쉽게 말해서, git으로 관리하는 프로젝트를 위해 일정 공간과 서비스를 대여해준다는 의미로 볼 수 있을 것이다. 간략하게 말하자면 이 둘의 차이는 아래와 같다.

Git
코드의 버전을 관리하고, 로컬에서 작업과 그 기록을 저장한다.

Github
Git의 버전기록을 토대로 온라인에서 협업을 더불어 더 쉽게 git을 사용할 수 있게 한다.


Staging Area

git에서는 Staging area 라는 것이 있다. git은 보통 원격저장소에 소스코드를 올리기 까지 add - commit - push의 흐름으로 이뤄지는데, 이를 식당으로 비유하자면 음식을 접시에 담고, 내보내는 것으로 볼 수 있다.
여기서 add는 음식을 담는 행위, commit은 쉐프에게 음식을 내기전에 확인을 받는 행위, push는 내보내는 행위로 본다면 staging area는 add와 commit 사이에서의 접시로 볼 수 있다.
commit을 하기전에 add를 통해 staging area에 먼저 올려줌으로써 디렉토리에서 원하는 부분만을 커밋하거나, 충돌을 쉽게 해결할 수 있고, 이미 커밋을 진행한 내용에 대해서 다시 커밋을 할 때도 훨씬 용이하게 해준다.


Snapshot

깃은 커밋 하고 난 뒤의 버전을 스냅샷으로 저장한다. 다른 버전관리툴 들은 원하는 파일 이외로 working directory안에 있는 모든 파일을 다운을 받아야하는데, git에서는 스냅샷을 통해서 원하는 버전에 접근할 수 있다.


Branch

branch는 다른 버전 관리 도구에서도 지원한다. 하지만 git에서는 위에서 언급한 Snapshot과의 시너지(???)로 복잡하지 않게 자신이 원하는 부분을 받아서 변경할 수 있다.

branch는 말 그대로 분기라는 표현이 적절하다.
하나의 소스코드에서 작업하는 개발자들이 원본 내용의 유실 없이 좀 더 효율적이라고 생각하는 코드나, 변경할 코드를 분기를 만들어 작성하고, 그 변경사항이 확정되었을 때는 원본 소스코드 즉, master branch(=main stream)에 병합을 통해서 원본코드를 수정할 수 있게 해준다. 뿐만 아니라 해당 branch에 대한 commit과 snapshot을 통해서 실수로 병합한 내용에 대해서도 손 쉽게 복원할 수 있으니 정말 강력한 기능이다.

아래는 각 branch와 master branch의 이해를 돕기위한 이미지이다.
git_branch.png
출처 :https://ohdowon064.tistory.com/3

다음 정리에서는 git의 사용에 대해 다룰 예정이다.

댓글남기기