형상관리(Git)
Intro
학생시절 레포트를 제출해야할때나, 상사에게 보고해야할 보고자료를 작성할때 위처럼 직접 보고자료에 대한 버전관리를 수행해본 경험이 있을 것이다.
단순 파일이나 보고서라면 상관 없겠지만, 복잡한 소프트웨어의 변경이력을 관리하기 위해서는 형상관리에 대한 개념과 형상관리를 지원하는 도구들에 대해 이해하고 다룰 줄 알아야 한다.
1. 형상관리
소프트웨어의 변경사항을 체계적으로 관리하고 통제하는 것.
변경사항이라 함은 파일의 추가, 삭제 뿐만 아니라 파일 내부의 소스코드의 수정내용 또한 포함 된다.
시간이 지남에 따라 변해가는 소프트웨어의 변경사항들을 관리하면서 소프트웨어의 형상을 체계적으로 관리하고 유지하므로 형상관리를 지원하는 도구를 "형상관리 시스템"이라고 부른다
2. Git
대표적인 형상관리 도구
소스코드를 저장하고 이력을 관리하는 저장소(repository)이다.
원하는 시점에 소스코드를 저장하거나, 저장지점으로 돌아가는 기능을 제공하여 프로젝트의 버전을 관리할 수 있다.
여러 pc에 소스코드를 저장시키거나 여러 pc에 저장한 내용을 하나로 병합하는 것이 가능하다.
3. GitHub
Git을 웹으로 이용할 수 있게 만든 원격 저장소(remote repository)이다.
여러 개발자가 하나의 원격 저장소를 이용하여 소스코드를 내려받거나, 병합하는 행위가 가능하다. 즉 프로젝트 단위로 하나의 원격저장소를 이용하여 협업이 가능한 것이다.
4. Git의 구조와 명령어들
1) 구조
2) Working Directory
프로젝트를 진행하는 폴더를 의미하며,
Working Directory내부에서 소스코드 변경 후 저장 시(ctrl+s) 자동으로git add명령어가 실행되며, "변경사항"을 Staging Area로 전달됨.Local Repository에 저장된 소스코드를 현재 프로젝트에merge명령어를 통해 병합가능하다.checkout명령어를 통해 작업Branch변경도 가능하다.
3) Staging Area
변경된 코드가
Local Repository에 저장되기 전에 머무르는 중간영역 이다.Local Repository에 저장할 파일을 선택하고commit명령어를 통해 저장할 수 있다.저장하기 싫다면 변경 전 코드로 돌아가면 자동으로 Staging Area에서 제외된다.
4) Local Repository
내 컴퓨터(PC)내에 존재하는 저장소이다. 소스코드의 변경/추가등의 이력을 기록한다.
Local Repository에 저장된 내용은push명령어를 통해Remote Repository로 밀어 넣을수 있고 fetch 명령어를 통해Remote Repository에서 당겨 올 수 도 있다.fetch와merge를 합친pull이라는 명령어도 존재한다. 단pull을 통한 자동병합보다는fetch후 수동병합을 권장한다.
5) Remote Repository
Git Hub에 존재하는 저장소이다.
5. Branch
Git에는 Branch를 통해 하나의 저장소 내에 여러 버전을 만들어 작업할 수 있다.
협업시
master브랜치를 여러개로 나누어 각 개발자는 독립적인 작업을 진행한다.각 branch로 가져간 코드는 원본에 영향을 미치지 않으므로 자유로운 작업이 가능하며, branch의 변경된 내용만
master에병합 시키는 PR(Pull Request)를 보낼 수 있다.프로젝트에 참여한 개발자들은 PR이 들어온 경우 요청 내용을 다같이 검토(Review)한다
문제가 없다면 PR(Pull Request)승인 후 변경 내용을
master에 병합한다
6. Git Branch 전략
1) Git Flow 전략
Git Flow는 기능개발(feature), 릴리즈(release), 버그수정(hot fixes), 개발(develop)의 목적에 맞춰 브랜치를 분리하여 관리하는 브랜칭 모델이다
가장 표준화된 깃 브랜치 사용방법으로, 브랜치별 역할 분담이 잘 되어 있어 효율적으로 브랜치를 사용할 수 있다.
규모가 큰 개발 팀에서 사용하는 방식
브랜치의 종류와 역할
master: 실제 프로덕션(운영) 환경에 배포되는 코드를 관리하는 브랜치로, 즉시 배포 가능한 상태를 유지해야 한다.develop: 개발의 중심 브랜치. feature(기능)브랜치의 코드들을 병합 하고, 병합완료 후 release로 소스코드를 다시 병합한다.feature/*: 새로운 기능 개발을 위한 브랜치. develop에서 분기하고, 기능개발 완료후 develop에 merger한다.release/*: 릴리즈(테스트)준비를 위한 브랜치. develop에서 분히 후 문제 없을 시 master, develop에 merge한다.hotfix/*: 운영환경에서 발생하는 버그를 수정하기 위한 브랜치. master에서 분기 후 , master와 deveop에 머지한다.
2) GitHub Flow
master브랜치와 feature 브랜치 2가지 종류로만 관리하는 간단한 브랜치 전략으로, 소규모 팀단위에서 사용하면 적절한 방식의 브랜치 관리 방법이다.(세미/파이널시 사용할 전략)
GitHub Flow 관리방법
matser브랜치는 항상 배포가능한 상태로 관리한다.
모든 기능은 master브랜치에서 분기 후 feature bracnh에서 작업 하구, PR(Pull Request)요청을 통해 리뷰 후 matser브랜치에 병합한다.(master에서 직접 작업하지 않는다)
기능이 완성된 브랜치는 자동/수동 삭제 처리하여 브랜치를 깔끔하게 관리한다.
Last updated