[Git] Git 제대로 알고 사용하기 - 1

이번 포스팅에서는 최근 시작한 인턴십에서 진행하는 신입사원 교육 중 흥미롭게 들었던 Git강의에 대한 정리를 하려고 합니다.

 

먼저 Git에 대한 이야기를 하기전에 Git을 왜 사용하게 됐는지 부터 얘기하려고 합니다.

(항상 기술을 사용할 때에는 왜? Why? 라는 질문을 습관화 합시다)

---

Version Control System (VCS)

VCS는 문서나 설계도, 소스 코드 등의 변경점을 관리해주는 소프트웨어입니다.

다음은 VCS을 사용하는 이유들 입니다.

• 변경점 관리
• 버전 관리 - 버전들 사이의 변경 사항, History등 관리
• 백업 & 복구 - 초창기 Git의 중점 point
• 협업

VCS에는 다음과 같은 종류들이 있습니다.

• Local VCS
• Centralized VCS
• Distributed VCS

Local VCS

Local VCS는 말그대로 로컬 컴퓨터에서 버전 관리를 하는 것입니다.

따로 서버에서 관리하지 않고 제 컴퓨터에 모든 파일을 저장하는 것입니다.

Centralized VCS

Centralized VCS는 모든 파일과 변경 History는 중앙 서버에서 관리합니다.

Centralized VCS를 통한 협업은 다음과 같은 단계로 진행됩니다.

1. 개발자가 중앙 서버에서 모든 파일을 받아온다 - Checkout/Update
2. 개발자가 개발후, 중앙 서버에 모든 파일을 반영한다 - Commit (단, update를 한번 하고 Push)

이런 Centralized VCS의 대표적인 프로그램은 SubVersion이라는 프로그램입니다.

Centralized VCS

단점

모든 파일을 중앙 서버에서 관리하다 보니, 중앙 서버에 장애가 발생하면 치명적입니다.

그 어떤 개발자도 중앙 서버에 장애가 생기면 코드를 받아와서 작업을 할 수 없습니다.

이렇기 때문에 중앙 서버에 올린 파일들을 정기적으로 백업을 해줘야 합니다.

 

협업상황에서 서로 Commit하려고 하면 문제가 생깁니다.

 

충돌이 발생해 파일이 망가지기도 하고, 정치적인 이유로 commit을 양보하게 되기도 합니다.

 

Commit을 하려는 개발자보다 더 선배인 개발자가 먼저 commit을 하겠다고 하면 양보할 수 밖에없고, 그 개발자 이후에 commit을 하고 발생하는 모든 충돌에 대해서는 후배 개발자가 충돌을 처리하고 commit해야 합니다. 충돌을 해결하고 commit하려 하는데 또 다른 선배 개발자가 commit하겠다고 하면 어떨까요?

---

Distributed VCS

그렇게 Distributed VCS가 탄생하게 됩니다.

Centralized VCS처럼 중앙 서버에서 최종 스냅샷을 가져오는 대신, 저장소 자체를 로컬 client에 복사합니다.

개발자는 복제된 로컬 저장소에서 작업을 하고, 언제든 중앙 저장소와 동기화 할 수 있습니다.

 

이런 Distributed VCS의 대표적인 프로그램은 Git이라는 프로그램입니다.

장점

중앙서버에 장애가 발생해도 작업을 할 수 있습니다.

중앙서버에 저장소가 날라가도, 로컬을 통해 복원할 수 있습니다.

로컬 저장소에서 작업하기 때문에 마음대로 commit할 수 있습니다.

 

Git의 장단점

장점

빠른 속도

단순한 구조

비선형적인 개발 (Branch)

완벽한 분산

Linux 커널 같은 대형 프로젝트에도 유용

단점

높은 난이도

대용량 바이너리 파일 관리의 어려움 (게임회사의 경우 Git안쓰는 회사도 많음)

아주 조금 수정한 변경 이력도 버전으로 관리됨