🐧Git

분산 버전 관리 시스템
→ 소스코드를 여러 개발 PC와 저장소에 분산하여 저장할 수 있다

Git의 장점

1. 소스 코드를 주고 받을 필요 없이 같은 파일을 여러 명이 동시에 개발 가능
2. 로컬 저장소에 히스토리가 유지됨 → 인터넷 연결이 끊겨도 개발 가능
3. 속도가 빠름 (각각 개발 PC가 서버가 되는 것이므로 중앙 서버의 일이 줄어든다)

동작 방식

1. Working Directory

• 작업 중인 파일들이 저장되는 디렉토리
  → 파일의 변경, 추가, 삭제 등이 자유롭게 이루어질 수 있음

2. Staging Area

• 커밋할 파일들의 변경 이력을 저장하는 공간
  → 커밋 하기 전에 변경된 파일들을 Staging Area에 추가하여 변경 이력 정리 가능

3. Local Repository

• 로컬 Git의 메타 데이터와 데이터 정보가 저장되는 영역
  → 커밋된 변경 이력이 저장되는 로컬 저장소 (커밋된 변경 이력을 Local Repository에 저장하며 변경 이력들은 브랜치와 같은 구조로 저장)

4. Remote Repository

• 깃허브 등의 웹서비스를 통한 온라인 저장소
  →Remote Repository에 Push하여 로컬 저장소의 변경 이력을 원격 저장소에 반영 (Pull 하여 원격 저장소의 변경 이력을 로컬 저장소에 가져옴. 협업 환경을 제공)

전체적인 흐름

• 파일 수정 → git add 명령어를 통해 파일 등록하면 staging area에서 git이 파일 변화 감시 → 파일을 git commit 명령어를 통해 로컬 저장소에 커밋 → git push 명령어로 로컬 저장소에서 원격 저장소로 보냄

버전 관리

파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템

1. 로컬 버전 관리

• 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리
  → 로컬 환경인 내 자신의 컴퓨터 내부에 존재. 마지막 버전으로부터 변경된 사항(patch)들만 저장.

2. 중앙집중식 버전 관리 시스템(CVCS)

• 모두가 공유할 수 있는 서버에 데이터베이스를 설치
  → 버전 공유 가능, 서버는 데이터베이스 관리의 임무만 가지고 있으므로 보다 더 안전하게 버전 관리가 가능
  3. 분산 버전 관리 시스템(DVSC)
• 서버에서 로컬로 특정 시점의 상태를 가져오지 않고 버전 관리되고 있던 저장소 그대로 가져옴
  • 여러 사용자들이 로컬로 가져온 데이터베이스를 이용하여 복원 가능
  • 버전이 로컬에 존재하므로 자신의 로컬에서 버전 관리 가능
  • 서버의 버전 관리 책임이 줄어듦

로컬/원격 저장소

로컬 저장소

• 자신의 컴퓨터 (개인 전용 저장소)

원격 저장소

• 서버 (공유하기 위한 저장소)

로컬 저장소와 원격 저장소 연결

로컬 저장소 만들기 → 임의로 문서 하나 커밋 → 깃허브에 원격 저장소 생성하고 원격 저장소 주소를 복사하여 입력 → 원격 저장소에 파일 업로드

😺GitHub

Git을 기반으로 소스코드와 파일을 저장하고 관리할 수 있는 웹 기반 호스팅 서비스

GitHub 브랜치 전략

브랜치 전략 : git 브랜치를 관리하기 위한 워크플로우

1. Git Flow

• Main 브랜치
  • master 브랜치 : 출시 가능한 프로적션 코드가 반영되는 브랜치. 배포된 버전은 Tag를 이용해 표시
  • develop 브랜치 : 다음 버전 개발을 위한 코드를 반영하는 브랜치. 출시 가능한 상태가 되면 master 브랜치로 merge
• Supporting 브랜치
  • feature 브랜치 : 기능을 개발하기 위한 브랜치. develop 브랜치에서 생성하고 개발이 완료되면 develop 브랜치로 머지(Recursive merge 사용 → 히스토리가 특정 기능 단위로 묶여 관리가 용이)
  • release 브랜치 : 소프트웨어 배포를 준비하기 위한 브랜치. develop 브랜치에서 생성하며 버전 이름 변경 및 사소한 버그 수정 가능
  • hotfix 브랜치 : 이미 배포된 master 브랜치에서 문제가 발생했을 때 문제를 해결 → 완료되면 master, develop 브랜치에 둘 다 머지.
    

2. GitHub Flow

• Git Flow보다 간단한 구조
• GitHub 환경에서 사용하기 적합한 브랜치 전략
• 흐름
  • 어떤 작업을 수행하기 위해 새로운 브랜치 생성 → 기본(메인) 브랜치에 영향을 주지 않기 위해
  • 원격지 브랜치에 수시로 push → 다른 디바이스에서 접근 가능. 백업 용도
  • Pull Request(PR) 생성 → 피드백이나 도움이 필요할 때 자신의 코드 공유, 리뷰 받을 수 있음. 개발이 완료되어 merge 준비가 되면 PR을 통해 master 브랜치로 반영 요구 가능
  • 리뷰 달기
  • 메인 브랜치로 merge
  • 브랜치 삭제 → 개발이 완료되었음을 알리는 동시에 오래된 브랜치에서 작업하는 것을 방지

3. GitLab Flow

• Git Flow의 경량화된 전략
• main 브랜치
  • develop 브랜치 생성 X → master 브랜치 사용
  • production 브랜치로 머지
  • 테스트 과정을 여러 단계로 단계화 하기 위해 원하는 만큼의 pre-production 브랜치를 만들 수 있음
• feature 브랜치
  • 기능 구현
  • master 브랜치에서 분기되고 머지됨
• production 브랜치
  • 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치
• pre-production 브랜치
  • master와 production 사이에서 변경 사항을 production 브랜치와 머지하여 배포하지 않고 테스트 서버에 배포하여 테스트 진행하거나 시간을 두고 반영할 수 있도록 도와줌

Pull Request 흐름

다른 사람의 저장소 내용을 가져와 수정한 후 적용 요청을 보내는 것

• 코드를 병합하는 과정에서 서로 코드를 확인하고 수정한 부분도 확인할 수 있다.

• Fork → clone, remote 설정 → 브랜치 생성 → 수정 작업 → add, commit, push → Pull Request 생성 → 코드 리뷰, Merge Pull Request → 동기화 및 브랜치 삭제

  용어 설명
  - fork : 다른 사용자의 저장소를 복사하여 내 계정으로 만드는 작업
  - clone : 초기화된 원격저장소를 복제하는 작업
  - remote : 원격 저장소 관리
  - add : 작업 디렉토리 상의 변경 내용을 Staging Area에 추가 (다음 변경을 기록할 때까지 변경사항을 모아 놓음 → commit 전까지는 git 저장소 변경 이력에 영향이 없다.)
  - commit : 코드 변경 사항을 저장소에 기록
  - push : 원격 저장소에 코드 변경분을 업로드

커밋 메시지, 브랜치 이름 컨벤션

커밋 메시지 : 변경 사항에 대한 설명과 의도 기록

• 커밋 메시지 구성
  • type : subject(제목) → type : 커밋 의도 명시(feat, fix, docs, style, refactor, test, chore) title : 50글자 이하, 마침표 X, 영문의 경우 동사를 가장 앞으로, 첫글자 대문자로
  • body : (본문) → 긴 설명이 필요한 경우 작성. 75글자 이하
  • footer : (꼬리말) → issue tracker ID 명시하고자 하는 경우 작성

브랜치 : 사용자가 독립적으로 작업을 진행할 수 있도록 돕는 작업 흐름

• 브랜치 이름
  • Main, Develop : 보통 그대로 사용
  • Hotfix : hotfix-…
  • Release : release-…
  • Feature : feature/기능명