Git & GitHub 실무 활용 정리 (기본용어 / Branch 종류)

IT에서 협업이란?

• Silo 극복, 비즈니스 효율, 커뮤니케이션 목적으로 활용
• IT 환경의 빠른 변화 > 대규모 N/W, OSS
• 요구사항 등에 대하나 유연한 대처
• 측정 가능한 Metric & Monitoring
• 지속적 Delivery
• Infra 활용 극대화

 

CI/CD (Continuous Integration/Continuous Delivery)
- 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법

(버전 관리 & 형상관리가 제대로 되어 있을 때 성립)

 

개발 협업을 위한 도구
GitHub	- 대표적인 코드 저장소 서비스 - 코드뿐만 아니라 이슈 트래커, 공동 개발, 위키 등 개발과 관련된 다양한 활동 가능
JIRA	- 프로젝트 관리 툴로 이슈 중심의 프로젝트 관리와 협업 가능 - 개발자로부터 디자이너, 비즈니스 멤버까지 폭넓게 사용 - 이슈 관리가 용이하며 이를 개인 단위 혹은 팀 단위에서 처리 및 관리가 가능하도록 설계
SourceTree	깃
JANDI	- 업무 커뮤니케이션 플랫폼

 

 

 

버전(형상)관리 - Source Configuration Management

• SDLC 상 코드 및 산출물의 체계적 관리를 위해 가시성, 추적성, 무결성을 확보하는 품질 보증 기법

 

 

버전관리 시스템이 갖춰야 할 요소
변경점 관리	- 여러 사용자들이 release한 시점을 관리
버전 관리	- 특정 시점에 Tag를 달아 버전 표시 - 브랜치(branch)를 여러 버전을 개발 가능
백업 & 복구	- 버전관리를 통해 복구 또는 다른 곳으로 백업을 가능케 함
협업	- 개별 사용자의 수정사항을 쉽게 공유

 

로컬 버전관리시스템

• 간단한 데이터베이스만으로도 구현 가능
• 단순하고 개인적인 프로젝트에 적합 (협업에서는 사용하기 힘듦)
• SPOF에 취약하며 내부 정보 관리가 중요
  
  
• RCS
  - 형상이 로컬에서 관리되는 초기 형태의 버전 관리 시스템

 

중앙집중식 버전관리시스템

• 다수 인원이 작업하는 경우 생기는 문제들을 해결하기 위해 개발된 도구
• 서버에 최종본 한 벌이 존재
• 사용자들은 이중 수정을 원하는 파일만 로컬에 받아 수정 후 서버에 올리게 됨
• 사용자 관리가 용이하며 중앙의 vSC 하나만 관리하면 됨
• 로컬 VCS와 마찬가지로 SPOF 존재
• 협업의 규모가 커지면 수정 충돌 문제 발생 가능
  
  
• Subversion(SVN)
  - 2000년에 개발되어 Apache 재단 소유로 넘어옴
  - 사용성이 좋으나 대형 프로젝트에 부적합
• CVS
  - 1990년대에 개발되어 널리 쓰였던 도구로 복잡해지는 개발환경에 부적합하여 지금은 쓰이지 않음

 

분산 버전관리 시스템

• 파일을 저장하는 서버가 있는 것은 중앙집중식과 동일하나 프로젝트에 관련된 저장소와 히스토리 전체가 로컬에 존재
• 저장소와 히스토리를 전부 복제
• 클라이언트가 단순히 최신 파일의 마지막 스냅샷을 checkout하지 않음
• 서버에 문제가 생겨도 복구가 가능하며 clone은 모든 데이터를 가짐
• 원격저장소가 존재하며 다양한 그룹과 협업 가능
• Git
  - 현재 VCS의 최고 점유율을 가진 도구로 다양한 IDE Tool이 내장

 

 

 

---

- 2005년에 리누스 토르발스에 의해 개발된 분산 버전관리 시스템

 

장점 

• 분산형
  - 인터넷 연결이 되지 않은 곳에서도 개발 진행 가능
  - 분산 버전관리이기 때문에 중앙 저장소가 삭제되어도 원상복구 가능
  
  
• 대규모 프로젝트
  - 각각의 개발자가 Branch에서 개발한 뒤, 본 프로그램에 합치는 merge 방식을 통한 병렬 개발 가능

 

Git 구조 (출처 : 앤조이[nJo2] 님)

 

 

 

Git 기본 용어

Repository		- 저장소는 히스토리, 태그, 소스의 가지치기 또는 branch에 따라 버전을 저장 - 작업자가 변경한 모든 히스토리를 확인 가능
Working Tree		- 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점 (흔히 말하는 폴더 구조)
Index		- Commit을 실행하기 전의 저장소와 Working Tree 사이에 존재하는 공감   (Staging 처리, Commit하고자 하는 파일만 등록)
Branch		- 가지 또는 분기점, 작업을 할 때 현재 상태를 복사하여 Branch에서 작업을 한 후   완전하다 싶을 때 Merge를 하여 작업함
	통합 Branch	- 언제든지 배포할 수 있는 버전을 만들 수 있어야 하는 브랜치 - 늘 안정적인 상태를 유지하는 것이 중요   (통합 Branch는 무조건 Master라고 볼 수 없음)
	토픽 Branch	- 기능 추가나 버그 수정과 같은 단위 작업을 위한 브랜치 - 하나의 목적을 갖고 별도로 만든 Branch 개념
Head		- 현재 작업 중인 Branch를 가리킴
Staging Area		- 저장소에 커밋하기 전에 커밋을 준비하는 위치
로컬 저장소		- 내 컴퓨터에 있는 로컬 저장소

 

 

 

Branch 종류

구분	브랜치명	설명
메인 브랜치	master	- 제품으로 출시될 수 잇는 브랜치 - 배포(Release) 이력을 관리하기 위해 사용, 배포 가능한 상태만을 관리
	develop	- 다음 출시 버전을 개발하는 브랜치 - 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적 상태일 때 master에 병합
보조 브랜치	feature	- 기능 개발 브랜치 - 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기 - 기본적으로 공유할 필요가 없기 때문에 자신의 로컬에서 관리
	release	- 이번 출시 버전을 준비하는 브랜치 - 배포를 위한 전용 브랜치 사용, 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속 할 수 있음
	hotfix	출시 버전에서 발생한 버그를 수정하는 브랜치

 

 

 

구분	Git	SVN
업로드	로컬저장소 저장 후 서버 업로드	중앙서버 업로드
충돌 가능성	Branch와 Merge를 통해 충돌 가능성 낮음	동시 업로드 시 충돌 가능성 多
네트워크	작업은 로컬에서, 업로드만 네트워크 사용	모든 작업에 네트워크 사용
히스토리	히스토리 관리 기능이 우수	상대적으로 약함