πŸš€Git-Flow / branch Strategy

jude0124Β·2023λ…„ 3μ›” 31일
1

ν˜•μƒκ΄€λ¦¬

λͺ©λ‘ 보기
1/1






πŸ“– 1. Definition


브랜치 μ „λž΅μ€ μ—¬λŸ¬ κ°œλ°œμžκ°€ ν•˜λ‚˜μ˜ μ €μž₯μ†Œλ₯Ό μ‚¬μš©ν•˜λŠ” ν™˜κ²½μ—μ„œ μ €μž₯μ†Œλ₯Ό 효과적으둜 ν™œμš©ν•˜κΈ° μœ„ν•œ μ›Œν¬ν”Œλ‘œμš°μ΄λ‹€.

기쑴의 ν˜•μƒκ΄€λ¦¬μ— 브랜치 μ „λž΅μ„ λ„μž…μ‹œν‚¨λ‹€λ©΄ , μ—¬λŸΏμ΄ ν•¨κ»˜ κ΄€λ¦¬ν•˜λŠ”λ° μžˆμ–΄ κ³΅ν†΅λœ κ·œμ•½μ„ μ§€ν‚€κΈ°λ§Œ ν•˜λ©΄ 되기 λ•Œλ¬Έμ— μ½”λ“œλ₯Ό μž‘μ„±ν•˜κ³  μ €μž₯ν•˜κ³  κ΄€λ¦¬ν•˜λŠ”λ° λ“œλŠ” λ§Žμ€ λΉ„μš©μ„ μ ˆκ°ν•  수 μžˆλ‹€.

μ΄λŸ¬ν•œ 브랜치 μ „λž΅μ˜ μ’…λ₯˜λ‘œλŠ” Github-flow, git-flow, gitlab-flow 등이 μžˆλ‹€.

이쀑 git-flowλ₯Ό ν•΄λ‹Ή flowκ°€ μ§€λ‹Œ branch μœ„μ£Όλ‘œ μ„€λͺ…ν•΄λ³΄κ³ μž ν•œλ‹€.



🌈 2. Branch의 μ’…λ₯˜




βšͺ 2.1. Main Branch


원격 μ €μž₯μ†Œμ—λŠ” 수λͺ…이 λ¬΄ν•œν•œ 두 가지 메인 λΈŒλžœμΉ˜κ°€ μ‘΄μž¬ν•œλ‹€.

λ°”λ‘œ main(master) λΈŒλžœμΉ˜μ™€ develop λΈŒλžœμΉ˜μ΄λ‹€.

main(master) λΈŒλžœμΉ˜μ™€ develop λΈŒλžœμΉ˜λŠ” 본래 이름 κ·ΈλŒ€λ‘œ μ‚¬μš©ν•˜λŠ” κ²½μš°κ°€ μΌλ°˜μ μ΄λ‹€.


πŸ”΅ 2.1.1. main(master) branch


  • μ œν’ˆμœΌλ‘œ μΆœμ‹œ 될 수 μžˆλŠ” 브랜치

  • mainμ—μ„œλŠ” μ‚¬μš©μžμ—κ²Œ 배포 κ°€λŠ₯ν•œ μƒνƒœλ§Œμ„ 관리

  • 배포(release) 이λ ₯을 κ΄€λ¦¬ν•˜κΈ° μœ„ν•΄ μ‚¬μš©


🟠 2.1.2. develop branch


  • λ‹€μŒ μΆœμ‹œ 버전을 κ°œλ°œν•˜λŠ” 브랜치

  • κΈ°λŠ₯ κ°œλ°œμ„ μœ„ν•œ 브랜치(feature)듀을 λ³‘ν•©ν•˜κΈ° μœ„ν•΄ μ‚¬μš©

  • 직접적인 κΈ°λŠ₯개발이 이루어 지지 μ•ŠμŒ (commit&push ❌ | Pull&Merge request β­•)

  • mainμœΌλ‘œλΆ€ν„° νŒŒμƒ, λͺ¨λ“  κΈ°λŠ₯이 μΆ”κ°€λ˜κ³  버그가 μˆ˜μ •λ˜μ–΄ 배포가λŠ₯ν•œ μ•ˆμ •μ μΈ μƒνƒœλΌλ©΄ develop을 main에 merge(병합)




πŸ”˜ 2.2. Supporting Branch


Supporting λΈŒλžœμΉ˜λŠ” νŠΉλ³„ν•œ μ΄μœ κ°€ μ—†λŠ” ν•œ main ν˜Ήμ€ develop에 반영된 ν›„ μ‚­μ œλ˜λ―€λ‘œ,

μœ ν•œν•œ 수λͺ…을 가진닀.

μ‚­μ œλ˜μ–΄λ„ ν•΄λ‹Ή 컀밋듀은 이미 develop ν˜Ήμ€ main에 μ˜¬λ €λ³΄λ‚΄μ‘ŒκΈ° λ•Œλ¬Έμ— μœ μ‹€λ˜μ§€ μ•ŠλŠ”λ‹€. (revert, reset κ°€λŠ₯)

Supporting 브랜치λ₯Ό 톡해 κ΅¬μ„±μ›κ°„μ˜ μˆ˜ν‰μ μΈ λ™μ‹œκ°œλ°œ, μ‰¬μš΄ κΈ°λŠ₯ 좔적이 κ°€λŠ₯ν•˜λ‹€.

supporting 브랜치의 μ’…λ₯˜λŠ” 세가지가 μžˆλ‹€.



πŸ’— 2.2.1. feature branch


  • κΈ°λŠ₯을 κ°œλ°œν•˜λŠ” 브랜치

  • feature λΈŒλžœμΉ˜λŠ” μƒˆλ‘œμš΄ κΈ°λŠ₯ 개발 및 버그 μˆ˜μ •μ΄ ν•„μš”ν•  λ•Œλ§ˆλ‹€ develop λΈŒλžœμΉ˜λ‘œλΆ€ν„° λΆ„κΈ°

  • feature λΈŒλžœμΉ˜μ—μ„œμ˜ μž‘μ—…μ€ 기본적으둜 κ³΅μœ ν•  ν•„μš”κ°€ 없기에 보톡 λ‘œμ»¬μ—μ„œ 관리

  • develop μœΌλ‘œλΆ€ν„° νŒŒμƒ, ν•΄λ‹Ή κΈ°λŠ₯ 개발 건이 μ™„λ£Œλ˜λ©΄ develop 브랜치둜 merge

  • 넀이밍 κ·œμΉ™μ€ feature/{κΈ°λŠ₯μš”μ•½} 의 ν˜•μ‹μ„ κ°€μž₯ 많이 μ‚¬μš©ν•œλ‹€.

  • μ΄μŠˆμΆ”μ μ„ μ‚¬μš©ν•œλ‹€λ©΄ λ‹€μŒκ³Ό 같은 ν˜•μ‹μ„ λ”°λ₯Έλ‹€. feature/{issue-number}-{feature-name}

Feature branch flow

  1. develop λΈŒλžœμΉ˜μ—μ„œ μƒˆλ‘œμš΄ κΈ°λŠ₯에 λŒ€ν•œ feature 브랜치λ₯Ό λΆ„κΈ°ν•œλ‹€.
  1. μƒˆλ‘œμš΄ κΈ°λŠ₯에 λŒ€ν•œ μž‘μ—…μ„ μˆ˜ν–‰ν•œλ‹€.
  1. μž‘μ—…μ΄ λλ‚˜λ©΄ develop 브랜치둜 mergeν•œλ‹€.
  1. 이미 μ‚¬μš©λ˜μ§€ μ•ŠλŠ”λ° λ‚¨μ•„μžˆλŠ” λΈŒλžœμΉ˜κ°€ λ§Žλ‹€λ©΄ μž‘μ—…μ— ν˜Όλž€μ„ 쀄 수 μžˆμœΌλ―€λ‘œ
    νŠΉλ³„ν•œ 상황이 μ•„λ‹Œ 이상 merge와 ν•¨κ»˜ ν•΄λ‹Ή 브랜치λ₯Ό μ‚­μ œν•œλ‹€.
    (ν•΄λ‹Ή 브랜치λ₯Ό μ‚­μ œν•˜μ—¬λ„ ν•΄λ‹Ή 브랜치의 commit 듀은 μƒμœ„ λΈŒλžœμΉ˜μ— 반영되고 μ €μž₯λ˜λ―€λ‘œ
    μ‚­μ œν•œλ‹€κ³  μœ μ‹€λ˜λŠ” 것은 μ—†μŒ)
  1. μƒˆλ‘œμš΄ κΈ°λŠ₯ 개발이 ν•„μš”ν•˜κ²Œ 되면 λ‹€μ‹œ 1λ²ˆλΆ€ν„° μ‹œμž‘ν•œλ‹€.
# develop λΈŒλžœμΉ˜μ—μ„œ 생성
$ git checkout -b feature/login develop




🟒 2.2.2. release branch


  • 이번 μΆœμ‹œ 버전을 μ€€λΉ„ν•˜λŠ” 브랜치, ν•΄λ‹Ή releaseκ°€ μ’…λ£Œ 되면 μ‚­μ œ

  • 배포λ₯Ό μœ„ν•œ μ „μš© 브랜치λ₯Ό λΆ„κΈ°ν•΄μ£Όλ©΄, ν•œνŒ€μ΄ ν•΄λ‹Ή 배포λ₯Ό μ€€λΉ„ν•˜λŠ” λ™μ•ˆ λ‹€λ₯ΈνŒ€μ€ λ‹€μŒ 배포λ₯Ό μœ„ν•œ κΈ°λŠ₯κ°œλ°œμ„ 계속할 수 μžˆλ‹€.

( ex_ AνŒ€μ€ 3버전 μΆœμ‹œ / BνŒ€μ€ 3-2버전 개발)

  • release λΈŒλžœμΉ˜λŠ” 배포λ₯Ό μœ„ν•œ μ΅œμ’…μ μΈ 버그 μˆ˜μ •, λ¬Έμ„œ μΆ”κ°€ λ“± 배포와 μ§μ ‘μ μœΌλ‘œ κ΄€λ ¨λœ
    μž‘μ—…μ„ μˆ˜ν–‰ν•œλ‹€.

  • release λΈŒλžœμΉ˜λŠ” develop μœΌλ‘œλΆ€ν„° νŒŒμƒ, λ²„κ·Έν”½μŠ€ 및 QA, ν…ŒμŠ€νŠΈλ₯Ό 마친 ν›„ μΆœμ‹œμ€€λΉ„κ°€ μ™„λ£Œλ˜λ©΄, developκ³Ό main으둜 반영

  • 넀이밍 κ·œμΉ™μ€ release-{x}.{y}.{z} 의 ν˜•μ‹μ„ λ”°λ₯Έλ‹€.




πŸ”΄ 2.2.3. hotfix branch


  • μΆœμ‹œ λ²„μ „μ—μ„œ λ°œμƒν•œ 버그λ₯Ό μˆ˜μ •ν•˜λŠ” 브랜치

  • λ°°ν¬ν•œ 버전에 κΈ΄κΈ‰ν•œ μˆ˜μ •κ±΄μ΄ λ°œμƒν•  경우, masterμ—μ„œ λΆ„κΈ°ν•˜λŠ” 브랜치
    μˆ˜μ • μ™„λ£Œ ν›„, master와 develop에 반영

  • 버그 ν˜Ήμ€ μˆ˜μ •μ‚¬ν•­μ΄ λ°œμƒν•˜μ—¬, λ°°ν¬ν•œ 버전을 μœ μ§€λ³΄μˆ˜ν•΄μ•Όν•˜λŠ” 경우, develop λΈŒλžœμΉ˜μ—μ„œ
    μˆ˜μ •ν•˜μ—¬ λ°°ν¬ν•˜κΈ°μ—λŠ” μ‹œκ°„μ΄ 많이 μ†Œμš”λ¨

  • νƒœκ·Έ 넀이밍은 hotfix-{x}.{y}.{z}의 ν˜•μ‹μ„ λ”°λ₯Έλ‹€.

hotfix branch flow

  1. λ°°ν¬ν•œ 버전에 κΈ΄κΈ‰ν•˜κ²Œ μˆ˜μ •ν•  λΆ€λΆ„ λ°œμƒ β‡’ master λΈŒλžœμΉ˜μ—μ„œ hotfix 브랜치 λΆ„κΈ°
  1. λ¬Έμ œκ°€ λ˜λŠ” λΆ€λΆ„ μˆ˜μ • ν›„, master λΈŒλžœμΉ˜μ— mergeν•˜κ³  배포
  1. ❗❗❗hotfix λΈŒλžœμΉ˜μ—μ„œμ˜ λ³€κ²½ 사항은 develop λΈŒλžœμΉ˜μ—λ„ mergeν•œλ‹€.❗❗❗



🎫 3. GIT TAG


πŸ”Ž 3.1. TAG μ‘°νšŒν•˜κΈ°


  • ν•΄λ‹Ή ν”„λ‘œμ νŠΈμ— νƒœκ·Έκ°€ μ‘΄μž¬ν•œλ‹€λ©΄ git tag λͺ…λ Ήμ–΄λ‘œ 이미 μ‘΄μž¬ν•˜λŠ” νƒœκ·Έλ₯Ό 확인할 수 있음

  • -l μ˜΅μ…˜μ„ μ΄μš©ν•΄ git tag -l "v3.1*" κ³Ό 같이 3.1 λ²„μ „λŒ€μ˜ λͺ¨λ“  νƒœκ·Έλ₯Ό μ‘°νšŒν•  수 있음

  • νƒœκ·Έμ™€ νƒœκΉ…λœ μ»€λ°‹μ˜ SHA-1 체크섬을 같이 λ³΄λŠ” 경우 git show-ref --tagsλ₯Ό μ‚¬μš©

πŸ“‹ 3.2. TAG μƒμ„±ν•˜κΈ°


νƒœκ·Έμ—λŠ” Lightweight νƒœκ·Έ, Annotated νƒœκ·Έκ°€ 쑴재

  • Lightweight νƒœκ·Έμ˜ 경우 git tag [tagλͺ…] 으둜 생성 (ν˜„μž¬κΉŒμ§€ μ»€λ°‹ν•œ μƒνƒœμ— νƒœκΉ…)

  • Annotated νƒœκ·Έμ˜ 경우 tag -a μ˜΅μ…˜μ„ 톡해 남길 수 있으며, μž‘μ„±μž, 이메일 , νƒœκΉ…λ‚ μ§œ ,νƒœκ·Έλ©”μ‹œμ§€κΉŒμ§€ 남길 수 있음. νƒœκ·Έλ©”μ‹œμ§€μ˜ 경우 -m μ˜΅μ…˜μ„ μ‚¬μš©

  • νŠΉμ • 컀밋에 νƒœκ·Έλ₯Ό λ‚¨κΈ°κ³ μž ν•œλ‹€λ©΄, git log λ₯Ό 톡해 ν•΄λ‹Ή μ»€λ°‹μ˜ SHA-1 체크섬 λ°Έλ₯˜λ₯Ό μ‘°νšŒν•œ λ’€, git tag -a [νƒœκ·Έλͺ…] [λŒ€μƒ μ»€λ°‹μ˜ 체크섬값] ν˜•μ‹μœΌλ‘œ μ‚¬μš© κ°€λŠ₯




참고자료

https://nvie.com/posts/a-successful-git-branching-model/

https://blog.hwahae.co.kr/all/tech/9507

https://inpa.tistory.com/entry/GIT-⚑️-github-flow-git-flow-πŸ“ˆ-브랜치-μ „λž΅

https://techblog.woowahan.com/2553/

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
https://git-scm.com/book/en/v2/Git-Basics-Tagging

https://dololak.tistory.com/348

profile
논리적인 사고와 좔둠을 지ν–₯ν•©λ‹ˆλ‹€.

0개의 λŒ“κΈ€