Git 정리 - 2

fork, clone

• fork 는 다른 사람의 레포지토리를 자신의 계정으로 가져오는 것

  • 이때 다른 사람의 레포지토리, 즉 원본을 ‘업스트림 레포지토리’ 라고 함
    반대로 fork 한 사람의 레포지토리는 ‘다운스트림 레포지토리’

• clone 은 특정 레포지토리의 코드를 자신의 워킹 디렉토리로 가져오는 것

Pull Request = Merge Request

• 코드를 메인 브랜치에 합치기 전에 검토를 요청하는 과정

• 작은 단위 (작업을 한번에 모든 과정을 다 하여 올리고 글 남기는 것은 X) 로 올릴 것!

  • 코드 완성 전 중간 리뷰를 원하면 Draft Pull Request

• Request 요청서

  Title: [여기에 제목 입력]
  
  Description: [여기에 설명 입력]
  
  Reviewers: [리뷰어 선택]
  Assignees: [담당자 선택]
  Labels: [라벨 선택] -> bug, feature, docs, urgent, fix 등등..

• PR 생성 전 체크리스트

  • 테스트

  • 주석 정리, debug용 log 출력 삭제, import 정리, 코드 정리

  • 커밋 메세지 정리

  • 반영될 브랜치 최신화 및 충돌 해결하기

  • 차이점 리뷰 정리

Branch 전략

• 브랜치는 역할을 지정하여 나눠 사용하는 전략을 취하는 것이 옳다

  • Dev, Stage, Prod 전략

    

    • Dev → 개발, 버그수정 등 개발자가 주로 작업하게 될 브랜치
      실험적 코드, 개발 중인 코드 등 완전하지 않은 변경사항 잔재

    • Stage → 배포 전 테스트 환경의 브랜치, QA, 통합 테스트들 진행
      실질적 배포 준비하는 스테이지

    • Prod → 실제 사용자가 이용할 환경의 브랜치, stable 및 배포가 가능해야함

    • Risky → 검증되지 않은 코드를 반영시 오류 위험성 표기
      Slow → 코드 양이 많아 질수록 느려짐
      FAT RELEASE → 한번에 많은 양을 반영하는 대규모 릴리즈시 문제
      작은 단위로 세분해야 QA, 통합 테스트를 통한 안정성 보유 가능

  • Main, HotFix, Release, Feature 전략

    

    • Feature → 기능 개발을 위한 브랜치, dev 같은 개발 브랜치에서 분기
      dev에서 feature/custom_manage, feature/api-1 등..

    • Release → 배포 전 최종 테스트, QA 를 위한 브랜치
      dev 같은 개발 브랜치에서 분기, 버그 수정 후 테스트 통과시 master merge 수행, 테스트 중 발견되는 버그는 Release에서 수정

    • Hotfix → 긴급 버그 수정, master에서 분기, 수정되면 dev와 master로 merge, 치명적 수정사항에 바로 수정

  • semantic Versioning 전략

    • major version.minor.patch → x.x.x 식 구성의 표기

      • 주버전.마이너버전.패치 식의 구성

        • 1.0.1 → 1버전의 1패치 (초기 제품에서 1번의 버그 수정)

        • 1.1.1→ 1버전의 1마이너 패치로 기능 추가 후 1번의 기능 버그 수정)

Squash merge

• squash 는 다수의 커밋을 하나로 합치는 것

  

  • 사진의 test1~4는 squash merge를 하지 않은 상태로 merge 함

    • 타 브랜치의 커밋이 master에서 보임

  • 하지만 squash를 진행하면?

    • 그 수가 많건 적건 간에 한 커밋으로만 진행되어 merge됨

    • 즉, 타 브랜치의 커밋 내역이 자잘하게 남지 않음

    • 왜 사용하는 걸까?

      • 이제 저 squash test1~4 가 사실은 결제 시스템 개발이라고 생각하면

        • 1 → 카드 결제 모듈 추가

        • 2 → 현금 결제 기능 추가

        • 3 → 카드 결제 모듈 추가에 오타 및 이미지 추가

        • 4 → 현금, 카드 결제 최종 테스트 및 최적화 수행, 오타 수정

          • 어느게 카드 결제 모듈로 최종인지 길어지면 길어질 수록 알기 힘듬

      💡

      Squash Merge로 하나로 합치면 결국 카드와, 현금결제 모듈이 추가된 최종본을 쉽게 찾을 수 있음!

Rebase

• rebase는 pull과 유사함

• merge commit의 기록이 남지 않음

• 실제 사용 예시

  • rebase 사용시

    

    • rebase_test 브랜치에서 새로 이제 2개의 rebase_test3,4.txt 파일 커밋

      

    • 이제 git rebase master 를 사용하면

      

      

  • pull 사용시

    

    • pull_test 브랜치에서 새로 이제 2개의 pull_test3,4.txt 파일 커밋

      

    • 이제 git merge master 을 사용하면 (여긴 서로 로컬간이라 merge)

      

    

• 사용하는 이유

  • git history 가 정돈되어 소스의 파악을 도움

    • 300개의 커밋 히스토리, 20개의 주 기능 작업이 히스토리 남는다면..
      어떻게 그걸 다 찾아볼 것인가라고 생각 해보면 됨
      가지가 다 쪼개진 것들을 하나하나 눌러가며..? 최악

commit --amend

• git commit --amend

  • 방금 한 커밋을 수정하는 것

  • git commit -m “feat: fhrmdls cnrk“

    • 영문으로 모르고 입력된 경우

      • git commit --amend -m “feat: 로그인 추가“

    • 이번엔 파일을 빠트려버림

      • git add 로그인 파일 추가

      • git commit --amend --no-edit (메시지 유지하고 커밋)

다음에 알아보면 좋을 개념

• git flow