Git

Git(23.08.28)

버전 관리

• 로컬 버전 관리 시스템
  • 파일 다른 이름으로 저장
  • 간단 하지만 실수 발생
  • DB를 활용해서 변경 사항을 기록하는 로컬 시트템 제작
• 중앙집중식 버전 관리 시스템
  • 파일을 저장하는 하나의 서버
  • 서버를 사용하는 다수의 클라이언트(서버 접속하는 프로그램)
  • 누가 무엇을 하는지 추적 가능
  • 중앙 서버에 의존하는 형태 → 중앙 서버 다운시 치명적
  • 서버 다운시 모든 사람이 업무 중단
• 분산 버전 관리 시스템
  • 클라이언트가 저장소를 통쨰로 복사함
  • 서버에 비의존적임 (서버가 이상이더라도 로컬에 저장)

git의 역사

• 리눅스가 사용하던 DVCS가 유료화 됨으로써 자체 도구 제작
• 리눅스가 분산 저장소 설계 함
  • 빠른속도
  • 단순 구조
  • 비 선형적 개발
  • 완벽한 분산
• 2005년 Git 탄생

git의 특성

• 대부분의 명령은 로컬에서 실행
  • 서버와 통신 비용이 없기에 빠른 조회 가능
• 각 파일의 변화를 시간순으로 관리
  • 델타를 저장 → 버전에 따른 변경 사항을 저장
  • 특정 버전으로 돌아갈떈 속도가 느림
• git은 스냅샷으로 저장
  • 파일이 달라지지 않으면 이전 버전의 링크만 저장
  • 특정 버전으로 되돌아갈때 속도가 빠름
• git은 무결성 하다
  • 데이터를 저장하기전 체크섬을 구하고 해당 체크 섬으로 데이터 관리
  • SHA-1 해시 사용 → 고유한 값을 가지기에 해당 파일의 해시로 저장
• git의 상태
  • Committed → DB에 안전하게 저장
  • Modified → 파일만 수정 아직 커밋 되지 않음
  • Staged → 곧 커밍 할거다.
• 깃은 어떻게 데이터를 저장하는가?
  • 커밋이 깃은 커밋 개체를 생성
  • 이런식으로 파일 저장 tree → blob → …
  • 결국 커밋을 가리키는 포인터 → 브랜치

브랜치와 머지

• branch → 가상의 작업 공간
• 이슈 발생시 새 브랜치를 하나 생성해 작업 진행 → hotfix 발생시 브랜치 새로 생성해 수정하고 머지

git-flow

• feature 브랜치
  • 특정 기능 하나에 대한 브랜치 그리고 개발 완료되며 다시 머지
  • fast-forward 사용하지 않음, 기능별로 개발한 커밋 분류하기 위해서
  • prefix/
• release 브랜치
  • 배포를 위한 브랜치
  • develop 브랜치 부터 시작됨
  • 소소한 버그 픽스
  • release 준비 완료시 develop / master 에 머지
  • 이 브랜치를 통해 develop은 바로 다음 기능
  • release/
• hotfix 브랜치
  • master로 부터
  • 긴급한 이슈 해결
  • release와 비슷함 ( 출발 브랜치의 차이 )
  • hotfix와 상관 없다면 develop은 개발 계속함
  • hotfix/

원격 저장소

• main 과 origin/main은 다르다

• 원격 저장소의 변경사항을 내려 받는것을 fetch라고 함

• fetch와 머지는 다르다.

• pull = fetch + 머지