Develop Branch sa Git — ano ito, layunin at prinsipyo ng paggana

Ano ang Develop Branch sa Git

Develop Branch (development branch) — ay isang matagalang branch sa Git Flow na nagsisilbing sentral na node para sa integrasyon ng code mula sa lahat ng developer. Ang mga feature branch ay pinagsasama dito pagkatapos ng completion ng development at pagdaan sa code review.

Ang code sa develop ay palaging nasa estadong handa para gumawa ng release, kahit na hindi pa ito nailalabas sa produksyon. Nangangahulugan ito na lahat ng feature sa develop ay dumaan sa review, testing, at integration checks, ngunit naghihintay pa rin sa kanilang release cycle.

Hindi tulad ng main, kung saan ang bawat bersyon ng code ay isang release, ang develop ay naglalaman ng tuluy-tuloy na daloy ng mga pagbabago. Ang mga commit sa develop ay lumalabas habang ang mga feature branch ay pinagsasama, na maaaring mangyari nang ilang beses sa isang araw.

Ayon sa datos ng Vincent Driessen, 2010, ang develop ay isang pangunahing elemento ng matagumpay na branching model, dahil inihihiwalay nito ang kasalukuyang trabaho mula sa mga bersyong handa nang ilabas.

Mga pagkakaiba ng develop at main branch

Ang pag-unawa sa mga pagkakaiba sa pagitan ng develop at main ay kritikal para sa tamang pagtatrabaho sa Git Flow. Ang mga branch na ito ay gumaganap ng iba't ibang function at may iba't ibang kinakailangan sa katatagan.

Ang paghihiwalay ng develop at main ay nagpapahintulot sa team na patuloy na mag-integrate ng bagong code nang hindi isinasakripisyo ang katatagan ng production version. Ang mga developer ay makikita ang kanilang code sa develop kaagad pagkatapos ng approval ng PR, kahit bago pa ang opisyal na release.

Papel ng develop sa Git Flow

Sa modelong Git Flow, ang develop ay sumasakop sa sentral na lugar sa pagitan ng feature branches (pinagmulan ng pagbabago) at release branches (paghahanda para sa paglabas). Ang pag-unawa sa hierarchy na ito ay pundasyon ng epektibong branching.

• Feature → Develop — bawat natapos na feature ay pinagsasama sa develop sa pamamagitan ng Pull Request na may code review.
• Develop → Release — kapag sapat na ang dami ng pagbabago para sa isang release, ang release branch ay ginagawa mula sa develop.
• Release → Main + Develop — pagkatapos ng huling paghahanda, ang release branch ay pinagsasama sa main (release) at pabalik sa develop (bug fixes).
• Hotfix → Main + Develop — ang mga kritikal na pag-aayos ay ginagawa mula sa main at pinagsasama sa parehong branch.

Ang ganitong istraktura ay ginagarantiyahan na ang develop ay palaging naglalaman ng pinakabagong bersyon ng code kasama ang lahat ng bagong feature, at ang main — ay naglalaman lamang ng na-verify na production code. Ito ay lalong mahalaga para sa mga mobile project na may mahabang review cycle sa App Store at Google Play.

Relasyon ng develop sa iba pang Git Flow branches

Ang develop ay nagsisilbing sentral na ugnayan sa pagitan ng feature, release, at hotfix branches. Ang pag-unawa sa mga direksyon ng pagsasama ay pundasyon para maiwasan ang mga conflict at pagkawala ng commit.

Mga kinakailangan sa kalidad ng code sa develop

Kalidad ng code sa develop ay dapat mataas, ngunit hindi absolute. Hindi tulad ng main, kung saan ang bawat error ay nangangahulugang agarang hotfix, ang develop ay nagpapahintulot ng maliliit na kakulangan na aayusin bago ang release.

Minimum na kinakailangan para sa code bago ang pagsasama sa develop:

• Compilation — ang code ay dapat mag-compile nang walang error. Ang sirang compilation sa develop ay humaharang sa trabaho ng buong team.
• Unit tests — lahat ng kasalukuyang test ay dapat pumasa. Ang bagong code ay dapat may test coverage na hindi bababa sa 70%.
• Code style — ang code ay dapat sumunod sa mga pamantayan ng formatting at pagpapangalan na tinatanggap sa team.
• Walang deprecated API — ang paggamit ng mga lumang pamamaraan ay hindi pinapayagan sa bagong code.

Ang mga awtomatikong pagsusuri sa CI/CD pipeline ay dapat tumakbo sa bawat push sa develop. Kung ang compilation ay masira, ang responsableng developer ay dapat ayusin ang problema sa loob ng isang oras o ibalik ang kanyang commit.

CI/CD checks para sa develop

Ang configuration ng GitHub Actions para sa develop ay ginagarantiyahan na ang bawat PR bago ang pagsasama ay dumadaan sa awtomatikong pagsusuri. Ang karaniwang pipeline ay may kasamang compilation, testing, at linting.

# GitHub Actions — pagsusuri ng develop pagkatapos ng pagsasama
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Mga patakaran sa pagsasama sa develop

Pagsasama sa develop ay dapat sumunod sa mahigpit na mga patakaran upang mapanatili ang katatagan ng integration branch. Ang paglabag sa mga patakarang ito ay humahantong sa mga conflict, sirang compilation, at pagkawala ng oras ng team.

• Sa pamamagitan lamang ng Pull Request — ang direktang push sa develop ay ipinagbabawal. Lahat ng pagbabago ay dumadaan sa code review.
• Hindi bababa sa isang approval — ang PR ay dapat makakuha ng approval mula sa kahit isang developer na hindi lumahok sa gawain.
• Squash merge — inirerekomenda na pagsamahin ang lahat ng commit ng feature branch sa isa kapag nagsasama sa develop para sa malinis na kasaysayan.
• Pagiging bago ng PR — bago ang pagsasama, ang PR ay dapat i-update batay sa huling commit ng develop (rebase o merge).

Ang patakaran ng pagiging bago ng PR ay lalong mahalaga. Kung ang feature branch ay ginawa isang linggo na ang nakalipas at ang develop ay nauna ng 50 commit, ang direktang pagsasama ay maaaring humantong sa mga conflict na mas mainayos sa konteksto ng PR, hindi sa develop.

Pagprotekta sa develop mula sa maling pagsasama

Branch protection rules (mga patakaran sa proteksyon ng branch) — ito ay mga setting sa antas ng GitHub, GitLab, o Bitbucket na pumipigil sa maling pagbabago sa develop. Ginagarantiyahan nila na kahit isang aksidenteng push ay hindi makakasira sa integration branch.

Mga inirerekomendang patakaran sa proteksyon para sa develop:

• Require pull request — ipagbawal ang direktang push sa develop. Lahat ng pagbabago sa pamamagitan lamang ng PR.
• Require approvals — hindi bababa sa 1-2 approval bago ang pagsasama ng PR.
• Require status checks — harangan ang pagsasama kung ang CI/CD pipeline ay hindi pumasa.
• Require up-to-date — ang PR branch ay dapat i-update batay sa develop bago ang pagsasama.
• Restrict push access — limitahan ang push access sa develop sa mga senior developer lamang.

Ang pag-configure ng proteksyon ng develop ay tumatagal ng 10 minuto, ngunit pumipigil sa mga linggo ng downtime na nauugnay sa sirang integration branch. Para sa mga mobile project na may multi-platform team, ito ay lalong mahalaga.

Mga halimbawa ng command para sa pagtatrabaho sa develop

Isaalang-alang natin ang isang tipikal na araw ng developer: sa umaga ay ina-update niya ang develop, gumagawa ng bagong feature branch, at pagkatapos matapos ang gawain ay pinagsasama ang mga pagbabago pabalik sa develop.

# Umagang synchronisation ng develop
git checkout develop
git pull origin develop

# Paggawa ng bagong feature branch mula sa develop
git checkout -b feature/add-push-notifications

# Pagtatrabaho sa feature...
git add . && git commit -m "Add FCM integration"

# Pag-update ng develop habang nagde-develop
git fetch origin develop
git rebase origin/develop

# Pagkatapos ng approval ng PR — pag-update ng lokal na develop
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Ang command na git pull sa develop ay nagsasagawa ng dalawang operasyon nang sabay: git fetch (kumukuha ng mga bagong commit mula sa server) at git merge (pinagsasama ang mga ito sa lokal na branch). Para sa develop, ito ang karaniwang paraan ng synchronisation.

Pagpapanumbalik ng develop pagkatapos ng sirang pagsasama

Kung ang code na sumira sa compilation ay nakapasok sa develop, kailangan kumilos nang mabilis. Bawat oras ng downtime ng develop ay nangangahulugan ng naka-block na trabaho ng buong team ng developer.

Kung ang code na sumira sa compilation ay nakapasok sa develop, gamitin ang git revert para gumawa ng bagong commit na nagbabalik sa mga problematikong pagbabago. Huwag gamitin ang git reset sa develop — ito ay magre-rewrite ng kasaysayan na mayroon na ang ibang mga kalahok.

# Paghahanap ng problematikong commit
git log --oneline develop

# Pagbabalik ng commit sa pamamagitan ng revert (ligtas)
git revert a1b2c3d

# Pagpapadala ng fix sa remote develop
git push origin develop

# Pagtingin ng mga pagbabago sa isang partikular na commit
git show a1b2c3d --stat