Release Branch sa Git — ano ito, layunin at proseso ng trabaho

Ano ang Release Branch sa Git

Release Branch (branch ng release) — ay isang pansamantalang branch sa Git Flow, na ginawa mula sa develop kapag nagpasya ang team na ang kasalukuyang set ng mga feature ay handa na para sa pag-release. Ito ay umiiral hangga't tumatagal ang huling paghahanda ng release — mula ilang oras hanggang ilang araw.

Ang pangunahing layunin ng release branch — i-freeze ang isang partikular na set ng mga feature para sa release, nang hindi humihinto sa pag-develop ng mga susunod na bersyon. Habang ang release branch ay inihahanda para ilabas, ang ibang developer ay maaaring magpatuloy sa pagsasama ng mga feature branch sa develop para sa susunod na release.

Sa release branch ay hindi ginagawa ang mga bagong feature — mga pag-aayos lamang ng bug, pag-update ng bersyon ng application, lokalisasyon, at dokumentasyon. Pagkatapos ng lahat ng gawain, ang release branch ay isinasama sa main (minarkahan bilang release) at pabalik sa develop (upang ang mga pag-aayos ng bug ay pumasok sa mga susunod na bersyon).

Ayon sa Atlassian, 2024, ang mga release branch ay kritikal para sa mga proyektong may regular na release cycle — tinitiyak nila ang predictability at stability ng proseso ng pag-release.

Siklo ng buhay ng release branch

Siklo ng buhay ng release branch mula sa paggawa hanggang sa pagtanggal ay may kasamang ilang yugto. Ang pag-unawa sa bawat yugto ay tumutulong sa team na i-synchronize ang mga aksyon at maiwasan ang mga pagkakamali.

1. Paggawa — mula sa huling commit ng develop ay ginawa ang isang branch na may pangalang release/2.5.0. Ang develop ay patuloy na tumatanggap ng mga feature branch para sa susunod na bersyon.
2. Paghahanda — sa release branch ay ina-update ang bersyon ng application sa build.gradle, Info.plist, at iba pang configuration file.
3. Pag-aayos ng bug — ang mga kritikal na bug na natagpuan sa proseso ng huling pagsubok ay inaayos. Mga bug lamang — walang bagong feature.
4. Huling pagsubok — ang QA team ay nagsasagawa ng regression testing sa release branch. Ang mga bagong bug ay ipinapadala para sa pag-aayos sa parehong branch.
5. Pagsasama sa main — ang release branch ay isinasama sa main na may --no-ff flag. Ang tag ng release ay ginagawa: v2.5.0.
6. Pagsasama sa develop — ang release branch ay isinasama pabalik sa develop, upang ang mga pag-aayos ng bug mula sa release ay pumasok sa kasalukuyang development.
7. Pagtanggal — ang release branch ay tinatanggal nang lokal at sa malayong server, dahil tapos na ang gawain nito.

Ang punto 6 — pabalik na pagsasama sa develop — ay madalas nakakalimutan, ngunit ito ay kritikal. Kung wala ito, ang mga pag-aayos ng bug na ginawa sa release ay hindi papasok sa develop, at sa susunod na release ang parehong mga pagkakamali ay maaaring lumitaw muli.

Mga karaniwang tagal ng mga yugto ng release branch

Ang haba ng buhay ng release branch ay depende sa pagiging kumplikado ng release at kalidad ng code sa develop. Sa karaniwan, ang paghahanda ay tumatagal ng 2 hanggang 5 araw ng trabaho para sa isang katamtamang laki ng mobile application.

Ano ang ginagawa sa release branch

Sa release branch ay isinasagawa ang isang mahigpit na limitadong set ng mga gawain. Anumang paglihis mula sa listahang ito ay lumalabag sa modelo ng Git Flow at lumilikha ng mga panganib para sa katatagan ng release.

Ang patakarang bawal ang mga bagong feature — ang pinakamahalaga sa release branch. Kung ang isang feature ay hindi umabot sa release, naghihintay ito sa susunod na cycle. Ang pagtatangkang itulak ang isang hindi tapos na feature sa release branch — ang pangunahing dahilan ng pagkaantala ng deadline at mga bug sa produksyon.

Pag-update ng bersyon sa mobile project

Sa release branch, ang numero ng bersyon ng application ay obligadong i-update. Para sa Android, ito ang mga field na versionCode at versionName sa build.gradle, para sa iOS — CFBundleShortVersionString sa Info.plist.

// build.gradle (app-level) — pag-update ng bersyon sa release branch
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Para sa iOS — pag-update ng Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Pagkakaiba ng release at hotfix

Ang mga baguhang developer ay madalas napagkakamalan ang release at hotfix branch, kahit na ang kanilang layunin ay pangunahing naiiba. Ang pagkakamali sa pagpili ng uri ng branch ay maaaring humantong sa pagkaantala ng kritikal na pag-aayos o pagkagambala sa proseso ng release.

• Pinagmulan — ang release ay ginawa mula sa develop, ang hotfix — mula sa main. Ito ang pangunahing pagkakaiba na tumutukoy sa lahat ng iba pa.
• Kagyatangan — ang release ay naka-iskedyul: ang team mismo ang nagpapasya kung kailan sisimulan ang paghahanda. Ang hotfix ay apurahan: ang problema sa produksyon ay nangangailangan ng agarang pag-aayos.
• Nilalaman — ang release ay maaaring magsama ng ilang pag-aayos at pag-update ng bersyon. Ang hotfix ay naglalaman lamang ng isang kritikal na pag-aayos.
• Pagsasama — ang release ay isinasama sa main at develop. Ang hotfix ay isinasama rin sa main at develop, ngunit may prayoridad.
• Haba ng buhay — ang release ay nabubuhay ng 1 hanggang 7 araw. Ang hotfix ay nabubuhay ng 30 minuto hanggang 1 araw.

Kung ang isang bug ay natuklasan sa proseso ng paghahanda ng release (sa release branch) — ito ay isang ordinaryong pag-aayos ng bug. Kung ang isang bug ay natuklasan sa produksyon (sa main) — ito ay hotfix, at ito ay ginagawa mula sa main, kahit na ang release branch ay mayroon na.

Mga patakaran sa pagpapangalan ng release branch

Ang isang pamantayang pagpapangalan ng release branch ay nagpapasimple sa pag-navigate sa repository at nagpapahintulot sa mga CI/CD system na awtomatikong matukoy na ang branch ay kabilang sa proseso ng release.

• release/X.Y.Z — karaniwang format ng Git Flow, kung saan ang X.Y.Z ay ang bersyon ng release. Halimbawa: release/2.5.0.
• release/pangalan — alternatibong format na may code name ng release. Halimbawa: release/merlin.
• release/petsa — format na may petsa ng release. Madalang gamitin dahil ang bersyon ay mas mahalaga kaysa petsa. Halimbawa: release/2024-12-01.

Ang format na release/X.Y.Z — ay mas gusto, dahil malinaw nitong iniuugnay ang branch sa numero ng bersyon na itatalaga sa release. Ito ay nagpapasimple sa paghahanap at awtomatikong pagproseso ng mga CI/CD script.

Estratehiya ng pabalik na pagsasama sa develop

Pabalik na pagsasama (merge back) ng release branch sa develop — isa sa pinakamahalaga at madalas napapansing operasyon. Kung wala ito, lahat ng pag-aayos ng bug na ginawa sa release ay mananatili lamang sa bersyon ng release at hindi papasok sa susunod na release cycle.

Ang proseso ng pabalik na pagsasama ay isinasagawa pagkatapos na ang release branch ay naisama na sa main. Una, ang release ay isinasama sa develop, pagkatapos — tinatanggal. Tinitiyak nito na ang develop ay naglalaman ng lahat ng pag-aayos na ginawa sa proseso ng paghahanda ng release.

Pagkatapos ng pabalik na pagsasama, posible ang mga conflict — lalo na kung sa develop ay lumitaw na ang mga bagong feature branch na nagbago ng parehong mga file. Ang developer na responsable para sa release ay nireresolba ang mga conflict na ito at itinutulak ang develop sa server.

Ang ilang team ay gumagamit ng rebase sa halip na merge para sa pabalik na pagsasama, upang manatiling linear ang kasaysayan. Gayunpaman, ang merge ay mas ligtas para sa develop dahil hindi nito isinusulat muli ang kasaysayan ng commit na maaaring ginagamit na ng ibang developer.

Mga halimbawa ng utos para sa pagtatrabaho sa release

Tingnan natin ang kumpletong siklo ng trabaho sa release branch: mula sa paggawa hanggang sa pagtanggal pagkatapos ng matagumpay na release ng mobile application na bersyon 2.5.0.

# 1. Paggawa ng release branch mula sa develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Pag-update ng bersyon at pag-aayos ng bug
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Pag-aayos ng mga bug (bugfixes lamang)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Pagpapadala ng release branch sa server
git push origin release/2.5.0

# 5. Pagsasama ng release sa main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Pabalik na pagsasama sa develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Pagtanggal ng release branch
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Ang mga utos 5 at 6 — dobleng pagsasama — ay kritikal. Una, natatanggap ng main ang release code at tag, pagkatapos ay nagsi-sync ang develop sa mga pag-aayos ng bug mula sa release. Kung ang hakbang 6 ay nilaktawan, ang mga pag-aayos mula sa release ay hindi papasok sa susunod na development cycle.

Automatisasyon ng proseso ng release

Para sa mga mobile project na may regular na release, ang proseso ng paggawa ng release branch at pag-update ng bersyon ay maaaring i-automate sa pamamagitan ng CI/CD scripts. Ang GitHub Actions ay nagpapahintulot na gumawa ng workflow na, sa pagpindot ng buton, ay gumagawa ng release branch na may awtomatikong pag-update ng bersyon.

Para sa mga mobile project na may regular na release, ang proseso ng paggawa ng release branch at pag-update ng bersyon ay maaaring i-automate sa pamamagitan ng CI/CD scripts. Ang GitHub Actions ay nagpapahintulot na gumawa ng workflow na, sa pagpindot ng buton, ay gumagawa ng release branch na may awtomatikong pag-update ng bersyon.

# GitHub Actions — automatisasyon ng paggawa ng release branch
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}