Feature Branch sa Git: ano ito, paano gumawa at magtrabaho gamit ang mga branch

Ano ang Feature Branch sa Git

Feature Branch (branch ng feature) — ay isang pansamantalang branch sa Git, na ginawa mula sa develop para sa pagbuo ng isang hiwalay na functionality. Hindi tulad ng mga matagalang branch na main at develop, ang mga feature branch ay umiiral nang limitadong oras — mula ilang oras hanggang ilang linggo.

Ang pangunahing layunin ng feature branch ay ihiwalay ang mga pagbabagong nauugnay sa isang gawain mula sa natitirang code. Ang developer ay maaaring mag-eksperimento, gumawa ng maraming commit, at kahit sirain ang code sa kanyang branch nang hindi naaapektuhan ang gawain ng ibang miyembro ng team.

Pagkatapos ng pagbuo, ang feature branch ay isinasama pabalik sa develop sa pamamagitan ng Pull Request na may sapilitang pagsusuri ng code. Pagkatapos ng pagsasanib, ang branch ay karaniwang binubura upang manatiling malinis ang repository.

Ayon sa Vincent Driessen, 2010, ang modelo ng Git Flow na may mga feature branch ay naging pamantayan ng industriya dahil sa malinaw na paghahati ng responsibilidad sa pagitan ng iba't ibang uri ng branch.

Daloy ng trabaho gamit ang Feature Branch

Daloy ng trabaho gamit ang feature branch ay binubuo ng isang serye ng mga hakbang na ginagawa ng developer para sa bawat bagong feature. Ang prosesong ito ay nagpapaliit ng mga conflict sa pagsasanib at tinitiyak ang kontrol sa kalidad ng code.

1. Paggawa ng branch mula sa huling commit ng develop. Ang developer ay lumipat sa develop, ina-update ito, at gumagawa ng bagong feature branch.
2. Pagbuo at mga commit sa feature branch. Ang developer ay gumagawa ng mga pagbabago, nagko-commit na may malinaw na paglalarawan, at pana-panahong nagpu-push ng branch sa remote repository.
3. Pag-sync sa develop — sa panahon ng pagbuo, ang pangunahing branch ay maaaring umusad. Ang developer ay nagsasagawa ng rebase o merge develop sa kanyang feature branch.
4. Paggawa ng Pull Request — kapag handa na ang feature, ang developer ay nagbubukas ng PR para sa pagsusuri ng code. Sinusuri ng team ang code at nag-iiwan ng mga komento.
5. Pagsasanib at pagbura — pagkatapos maaprubahan ang PR, ang branch ay isinasama sa develop at binubura pareho nang lokal at remote.

Ang pana-panahong pag-sync sa develop ay kritikal na mahalaga. Kung gaano katagal nabubuhay ang feature branch nang hindi isinasama ang mga pagbabago mula sa develop, mas mataas ang posibilidad ng mga conflict sa huling pagsasanib.

Dalas ng pag-sync ng feature branch

Mga patakaran sa pagpapangalan ng feature branch

Pagpapangalan ng branch — mahalagang bahagi ng disiplina ng team. Ang isang pamantayang pagpapangalan ay nagbibigay-daan upang mabilis na matukoy kung anong gawain ang ginagawa at kung sino ang gumaganap nito.

• feature/pangalan — ang prefix na feature/ ay ginagamit sa klasikong Git Flow. Halimbawa: feature/added-auth-module.
• feature/JIRA-123-paglalarawan — pag-uugnay sa numero ng gawain sa tracking system. Halimbawa: feature/PROJ-42-add-login.
• feature/uri/pangalan — pinalawak na format na may pagtukoy sa uri ng gawain. Halimbawa: feature/feat/analytics-dashboard.

Ang paggamit ng ID ng gawain mula sa JIRA, Trello, o ibang sistema ay pinakamahusay na kasanayan. Ito ay awtomatikong nag-uugnay ng code sa gawain at pinapasimple ang paghahanap ng branch sa pamamagitan ng git log.

Proseso ng Pull Request

Pull Request (o Merge Request sa GitLab) — ay isang kahilingan na isama ang feature branch sa develop. Ang PR ay hindi lamang isang teknikal na operasyon, kundi isang proseso ng pagsusuri ng code ng team na nagpapabuti sa kalidad ng code at nagpapalaganap ng kaalaman sa loob ng team.

Ang isang mahusay na PR ay naglalaman ng pamagat na may maikling paglalarawan ng gawain, link sa ticket, at paglalarawan ng mga pagbabago. Dapat ipahiwatig ng developer kung ano ang eksaktong ginawa, anong mga file ang binago, at kung may mga potensyal na panganib para sa ibang bahagi ng proyekto.

Sinusuri ng team ang code sa PR, nag-iiwan ng mga komento, humihiling ng mga pagbabago (change requests), at nag-aapruba ng pagsasanib (approve). Pagkatapos ng aprobasyon, isinasagawa ang merge o squash merge.

Ang karaniwang oras ng pagsusuri ng PR sa mobile development ay 4 hanggang 24 na oras. Ang library na Danger ay nag-automate ng bahagi ng mga pagsusuri, nagpapatakbo ng mga linter at test nang direkta sa PR.

Mga rekomendasyon para sa paggawa ng mahusay na PR

• Sukat — hindi hihigit sa 300-400 linya ng pagbabago. Ang malalaking PR ay mahirap suriin, bumababa ang kalidad ng pagsusuri.
• Isang PR — isang gawain — iwasan ang paghahalo ng hindi nauugnay na pagbabago sa isang kahilingan.
• Screenshot — para sa mga pagbabago sa UI, maglakip ng screenshot bago at pagkatapos.
• Test — para sa bagong functionality, sumulat ng unit test at isama ang mga ito sa PR.

Mga estratehiya sa pagsasanib ng feature branch

Pagkatapos maaprubahan ang PR, ang feature branch ay maaaring isama sa develop sa iba't ibang paraan. Ang pagpili ng estratehiya sa pagsasanib ay nakakaapekto sa kasaysayan ng commit at posibilidad ng pagbabalik ng mga pagbabago.

• Merge commit — gumagawa ng commit ng pagsasanib, pinapanatili ang buong kasaysayan ng commit ng feature branch. Ang kasaysayan ay nananatiling kumpleto, ngunit ang graph ng pagsasanga ay nagiging mas kumplikado.
• Squash merge — pinagsasama ang lahat ng commit ng feature branch sa isa at idinadagdag ito sa ibabaw ng develop. Nagiging mas malinis ang kasaysayan, ngunit nawawala ang impormasyon tungkol sa mga intermediate na commit.
• Rebase and merge — muling isinusulat ang mga commit ng feature branch sa ibabaw ng huling commit ng develop at isinasama nang walang karagdagang commit. Ang kasaysayan ay nananatiling linear.

Para sa mga mobile project na may madalas na release, kadalasang ginagamit ang squash merge: nagbibigay ito ng malinis na kasaysayan sa develop, habang ang mga detalye ng pagbuo ay nananatili sa paglalarawan ng PR at sa gawain ng tracker.

Mga karaniwang pagkakamali sa pagtatrabaho gamit ang Feature Branch

Kahit ang mga batikang developer ay nagkakamali sa pagtatrabaho gamit ang feature branch. Ang pag-alam sa mga karaniwang problema ay tumutulong upang maiwasan ang pagkawala ng oras at data.

• Masyadong mahabang buhay ng branch — ang feature branch ay nabubuhay nang higit sa 2-3 linggo nang walang pag-sync sa develop, na humahantong sa malalaking conflict sa pagsasanib.
• Commit na may hindi malinaw na paglalarawan — ang mga mensaheng tulad ng “fix” o “update” ay hindi nagpapaliwanag kung ano ang binago at kung bakit.
• Paghahalo ng gawain — sa isang feature branch, dalawang hindi nauugnay na feature ang binuo, na ginagawang imposible ang piling pagbabalik.
• Kawalan ng pag-sync — ang developer ay hindi gumagawa ng git fetch at hindi ina-update ang develop, kaya sa huling merge ay lumilitaw ang mga conflict.

Ang pinakamahusay na paraan upang maiwasan ang mga problemang ito ay ang magkasundo sa mga patakaran ng trabaho sa simula ng proyekto at gumamit ng mga awtomatikong pagsusuri sa CI/CD pipeline.

Mga halimbawa ng command para sa Feature Branch

Isaalang-alang natin ang isang praktikal na senaryo: isang developer ay nagsisimula ng isang bagong feature ng authentication sa isang mobile app. Gumagawa siya ng feature branch, nagtatrabaho sa code, at tinatapos ang gawain sa pamamagitan ng Pull Request.

# Pag-update ng develop at paggawa ng feature branch
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Pagtatrabaho sa feature: mga commit
git add src/ui/login/
git commit -m "Add login screen layout"

# Pagpapadala ng feature branch sa server
git push origin feature/add-login-screen

# Pag-sync sa develop (rebase)
git fetch origin develop
git rebase origin/develop

# Pagkatapos maaprubahan ang PR: pag-update ng local develop at pagbura ng branch
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Ang command na git branch -d ay bumabura ng branch pagkatapos lamang na ang mga pagbabago nito ay ganap na naisama. Kung ang branch ay hindi naisama, ang Git ay magmumungkahi na gamitin ang git branch -D para sa sapilitang pagbura — gamitin ang flag na ito nang may pag-iingat.

Automation ng mga pagsusuri sa feature branch

Ang CI/CD pipeline ay dapat tumakbo para sa bawat feature branch bago gumawa ng PR. Ito ay nagpapahintulot sa pagtuklas ng mga problema sa maagang yugto, bago ang code ay mapunta sa pagsusuri ng ibang developer.

# GitHub Actions para sa pagsusuri ng feature branch
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Sinusuri ng pipeline kung ang code ay nagko-compile, pumapasa ang mga test, at ang estilo ng code ay sumusunod sa mga pamantayang tinatanggap sa team. Pagkatapos lamang pumasa sa lahat ng pagsusuri ay maaaring gumawa ng Pull Request.