Git at kontrol ng bersyon sa mobile development: ano ito, mga pangunahing utos at paano ito gumagana

Kontrol ng bersyon at Git: ano ito?

Git ay isang distributed na sistema ng kontrol ng bersyon (VCS) na nilikha ni Linus Torvalds noong 2005 para sa pag-develop ng Linux kernel. Hindi tulad ng centralized na mga sistema (SVN, CVS), nag-iimbak ang Git ng kumpletong kopya ng kasaysayan ng proyekto sa bawat computer ng developer. Nangangahulugan ito na maaari kang gumawa ng commit, mag-browse ng kasaysayan at lumikha ng mga sanga kahit walang koneksyon sa internet.

Ang Git ay gumagana sa mga snapshot — bawat commit ay nagse-save ng estado ng lahat ng file ng proyekto sa oras ng pag-save. Kung ang isang file ay hindi nagbago, ang Git ay lumilikha ng isang reperensya sa nakaraang bersyon, makatipid ng espasyo. Ayon sa pagsusuri ng GitHub (2025), ang average na repositoryo ay naglalaman ng 1,200 commit at 15 sanga.

Sa IT Sectr, gumagamit kami ng Git mula noong 2017 sa lahat ng proyekto. Ipinapakita ng aming karanasan na ang tamang konpigurasyon ng Git mula sa unang araw ay nakakatipid sa koponan ng hanggang 30% ng oras sa pagsasama at paglutas ng mga alitan. Ang Git ay naging de facto na pamantayan — sinusuportahan ito ng lahat ng modernong IDE (Android Studio, Xcode, VS Code) at mga sistema ng CI/CD.

# Pangunahing setup ng Git
git config --global user.name "Iyong Pangalan"
git config --global user.email "iyong@email.com"

# Paggawa ng bagong repositoryo
git init my-project
cd my-project

# Pagdagdag ng mga file at commit
git add README.md
git commit -m "Initial commit"

# Pagtatrabaho sa malayong repositoryo
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Ang code sa itaas ay nagpapakita ng pangunahing pagkakasunod-sunod: pagsisimula ng repositoryo, unang commit at pag-publish sa malayong server. Ang utos na git init ay lumilikha ng nakatagong folder na .git na mag-iimbak ng buong kasaysayan ng proyekto. Ang bawat git commit ay lumilikha ng restore point na maaari mong balikan anumang oras.

Mga pangunahing konsepto: Repository, Branch, Commit

Ang pag-unawa sa tatlong pangunahing konsepto — Repository, Branch at Commit — ay mahalaga para sa pagtatrabaho sa anumang sistema ng kontrol ng bersyon. Ang repositoryo ay isang lalagyan para sa buong proyekto. Ang commit ay isang naka-save na estado ng mga file. Ang branch ay isang hiwalay na linya ng pag-develop.

Repository (repositoryo) ay maaaring lokal (sa iyong computer) o malayo (sa server ng GitHub, GitLab). Bawat developer ay nagko-clone ng malayong repositoryo sa kanilang makina at nagtatrabaho sa lokal na kopya. Ang mga pagbabago ay nisi-sync sa pamamagitan ng push (pagpapadala) at pull (pagkuha). Sa distributed na kontrol ng bersyon, bawat developer ay nag-iimbak ng kumpletong kopya ng kasaysayan.

Branch (sanga) ay isang pointer sa isa sa mga commit. Ang mga sanga ay nagpapahintulot ng parallel na pag-develop: isang developer ay gumagawa sa bagong feature (feature branch), isa pa ay nag-aayos ng bug (hotfix branch), isang pangatlo ay naghahanda ng release (release branch). Ayon sa GitLab Flow (2025), ang average na proyekto ay may 3–5 aktibong sanga nang sabay-sabay.

Commit ay isang yunit ng pagbabago. Bawat commit ay naglalaman ng natatanging hash (SHA-1), mensahe, may-akda at timestamp. Ang mabuting kasanayan ay gumawa ng maliliit na makabuluhang commit na may naglalarawang mga mensahe — pinapasimple nito ang Code Review at pagbabalik ng mga pagbabago. Ang kontrol ng bersyon sa pamamagitan ng commit ay nagbibigay sa iyo ng kumpletong kasaysayan ng proyekto.

Feature Branch

Feature Branch (sanga ng feature) ay isang pansamantalang sanga na ginawa mula sa develop o main para sa pag-develop ng isang tiyak na gawain. Pagkatapos matapos ang trabaho, ang sanga ay isinasama pabalik sa pamamagitan ng Pull Request at binubura. Ang kasanayang ito ay nagpapahintulot na ihiwalay ang mga pagbabago nang hindi naaapektuhan ang katatagan ng pangunahing codebase.

Karaniwang workflow: gumawa ng sanga feature/add-login → gumawa ng ilang commit → gumawa ng Pull Request → dumaan sa Code Review → isama sa develop. Sa IT Sectr ginagamit namin ang eksaktong approach na ito: bawat Jira task ay tumutugma sa isang hiwalay na feature branch. Pinapasimple nito ang pagsubaybay ng mga pagbabago at pagbabalik kung kinakailangan.

Rebase vs Merge

Merge ay lumilikha ng merge commit na pinagsasama ang dalawang sanga. Pinapanatili nito ang buong kasaysayan, kabilang ang parallel na mga linya ng pag-develop. Ang Rebase ay muling nagsusulat ng kasaysayan: kumukuha ito ng mga commit mula sa isang sanga at "muling inaplay" ang mga ito sa ibabaw ng isa pa, lumilikha ng isang linear na kasaysayan.

Ang Merge ay mas angkop para sa pampublikong mga sanga at malalaking koponan kung saan mahalaga ang kronolohiya. Rebase ay maginhawa para sa personal na feature branch bago gumawa ng PR — ginagawa nitong mas malinis at mas nauunawaan ang kasaysayan. Gayunpaman, ang rebase ay hindi dapat ilapat sa mga sanga na pinagtatrabahuhan ng ibang mga developer, dahil muling isinusulat nito ang kasaysayan.

# Paggawa at paglipat sa feature branch
git checkout -b feature/add-login main

# Pagtatrabaho sa sanga
git add login-screen/
git commit -m "Add login screen layout"

# Rebase sa pinakabagong main bago ang PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push sa malayong repositoryo
git push origin feature/add-login

Ang halimbawang ito ay nagpapakita ng isang karaniwang workflow: paggawa ng feature branch mula sa main, ilang commit at rebase para makakuha ng malinis na linear na kasaysayan bago ipadala para sa pagsusuri. Ang approach na ito ay nagbabawas ng mga alitan sa pagsasama.

Git Flow vs Trunk-Based Development

Git Flow at Trunk-Based Development ay dalawang pangunahing estratehiya ng kontrol ng bersyon na tumutukoy kung paano inaayos ng isang koponan ang trabaho sa Git. Ang pagpili ay depende sa laki ng koponan, dalas ng release at mga kinakailangan sa katatagan.

Git Flow ay isang mahigpit na modelo na may maraming permanenteng sanga: main (release code), develop (kasalukuyang pag-develop), feature/* (bagong feature), release/* (paghahanda ng release) at hotfix/* (apurahang pag-aayos). Ang modelong ito ay mabuti para sa mga proyekto na may malinaw na release cycle (hal., mobile app na may bersyon 1.0, 2.0).

Trunk-Based Development ay isang approach na may iisang pangunahing sanga (trunk/main) kung saan ang lahat ng developer ay nagsasama ng mga pagbabago nang ilang beses sa isang araw. Ang feature flag ay ginagamit upang itago ang hindi kumpletong feature. Ang approach na ito ay popular sa web development at startup kung saan mahalaga ang bilis ng paghahatid.

Git Flow

Git Flow, na iminungkahi ni Vincent Driessen noong 2010, ay nananatiling isa sa pinakasikat na modelo. Ang pangunahing bentahe nito ay ang mahigpit na paghihiwalay ng code ayon sa mga yugto ng lifecycle. Ang sanga main ay naglalaman lamang ng release code, develop ay naglalaman ng kasalukuyang pag-develop, at feature branch ay naghihiwalay ng bagong feature sa isa't isa.

Ang hotfix branch ay ginawa mula sa main para sa apurahang pag-aayos at pagkatapos isama ay isinasama pabalik sa parehong main at develop. Release branch ay ginawa mula sa develop kapag handa na ang koponan para sa isang release. Ang mga ito ay naglalaman lamang ng bug fix at metadata (bersyon, build). Pagkatapos ng release, ang release branch ay isinasama sa main at develop. Ayon sa isang survey ng JetBrains (2024), 37% ng mga koponan ay gumagamit ng Git Flow. Ang modelong ito ng kontrol ng bersyon ay nananatiling pamantayan para sa mga proyekto na may nakapirming release.

# Halimbawa ng Git Flow: pagsisimula ng trabaho sa isang release
git checkout -b release/1.2.0 develop

# Pag-aayos ng bug sa release branch
git commit -m "Fix login button crash"

# Pagkumpleto ng release — isama sa main at develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Pagbura ng release branch
git branch -d release/1.2.0

Ang code ay naglalarawan ng paggawa ng release branch, pagpapatatag nito at pagsasama sa pangunahing mga sanga. Ang flag na --no-ff ay ginagarantiyahan ang isang merge commit, na pinapanatili ang impormasyon na ang mga pagbabago ay nagmula sa release branch.

Pull Request at Code Review

Pull Request (PR) ay isang mekanismo kung saan ang isang developer ay nagmumungkahi ng mga pagbabago mula sa kanilang sanga patungo sa pangunahing sanga. Ang PR ay isang pangunahing elemento ng kontrol ng bersyon sa pagtutulungan ng koponan — hindi lamang ito isang paraan upang isama ang code, kundi isang proseso ng talakayan, pagsusuri at pagsuri ng kalidad. Sa GitLab, ang katulad na mekanismo ay tinatawag na Merge Request (MR), ngunit ang diwa ay pareho: ipaalam sa koponan ang tungkol sa mga pagbabago at makakuha ng pag-apruba.

Ang isang mabuting PR ay dapat maliit (hanggang 300 linya ng code), nakatutok sa isang gawain at naglalaman ng paglalarawan kung ano ang ginawa at bakit. Ayon sa isang pag-aaral ng Google (2025), ang PR na higit sa 400 linya ay dalawang beses na mas matagal suriin at ang posibilidad na makita ang bug ay bumababa ng 30%. Ang Code Review ay pagsusuri ng code ng ibang developer bago ang pagsasama.

Sa IT Sectr, isinasagawa namin ang mandatoryong Code Review para sa bawat PR. Ito ay hindi lamang nagpapabuti sa kalidad ng code kundi tumutulong din sa pagpapalaganap ng kaalaman sa loob ng koponan. Sinusuri ng Code Review: kung ang code ay sumusunod sa mga prinsipyo ng arkitektura, kung may mga bug, kung may sapat na pagsubok, kung ang mga variable ay wastong pinangalanan. Lahat ng komento ay pinag-uusapan sa PR hanggang sa pagsasama.

Platform: GitHub, GitLab, Bitbucket

Ang Git ay isang protocol, ngunit para sa pakikipagtulungan kailangan ang isang platform ng kontrol ng bersyon na nagbibigay ng web interface, pamamahala ng access, CI/CD at mga kasangkapan sa pagsusuri. Tatlong platform ang nangingibabaw sa merkado: GitHub, GitLab at Bitbucket.

GitHub ay ang pinakamalaking platform na may higit sa 56 milyong developer. Pag-aari ng Microsoft, nag-aalok ito ng Actions (CI/CD), Pages (hosting), Discussions at Copilot. Ang libreng plano ay may kasamang walang limitasyong pribadong repositoryo para sa koponan hanggang 3 tao. Ang GitHub ay popular sa open-source community.

GitLab ay isang kumpletong DevOps platform na may integrated CI/CD, container registry at pamamahala ng imprastraktura. Hindi tulad ng GitHub, ang GitLab ay maaaring i-install sa iyong sariling server (Self-Managed). Ang Bitbucket ng Atlassian ay mahigpit na integrated sa Jira at Confluence, na ginagawa itong pagpipilian para sa mga koponan na gumagamit na ng Atlassian ecosystem.