Git — ano ito, mga prinsipyo ng paggana at mga utos

Ano ang Git?

Git — ay isang distributed version control system (VCS) na sumusubaybay sa mga pagbabago sa file at nagpapahintulot sa maraming developer na magtrabaho nang sabay-sabay sa iisang proyekto. Hindi tulad ng centralized system, sa Git bawat developer ay may kumpletong kopya ng repository, kasama ang buong kasaysayan ng mga pagbabago, na ginagawang lumalaban ang system sa pagkawala ng data at hindi nangangailangan ng permanenteng koneksyon sa central server.

Nagsimula ang kasaysayan ng Git noong 2005, nang lumikha si Linus Torvalds ng bagong VCS matapos bawiin ng BitKeeper ang libreng lisensya para sa kanilang system para sa mga developer ng Linux kernel. Ang mga layunin ay: bilis, simple ng arkitektura, suporta para sa non-linear development sa pamamagitan ng pagsasanga at ganap na distributedness. Sa loob ng 3 buwan isinulat ni Torvalds ang core ng Git, at makalipas ang isang taon ang proyekto ay lumipat sa self-management sa ilalim ng pamumuno ni Junio Hamano.

Ayon sa survey ng Stack Overflow (2024), 93.9% ng mga propesyonal na developer ay gumagamit ng Git, na ginagawa itong dominanteng version control system sa industriya. Ang pinakamalapit na kakumpitensya — Subversion (SVN) — ay ginagamit lamang sa 5.2% ng mga proyekto, pangunahin sa malalaking corporate environment na may centralized process.

Paano gumagana ang Git: repository at mga commit

Git repository — ay isang direktoryo kung saan sinusubaybayan ng Git ang mga pagbabago ng lahat ng file. Sa loob ng direktoryo ay may nakatagong folder na .git, kung saan nakaimbak ang lahat ng object ng system: mga commit, tree, blob at reference. Kapag ang developer ay gumawa ng commit, hindi kinokopya ng Git ang mga file nang buo — gumagawa ito ng snapshot ng estado at nag-iimbak ng reference dito.

Bawat commit ay naglalaman ng: natatanging SHA-1 hash (40 character), reference sa nakaraang commit (parent), may-akda, petsa, mensahe ng commit at reference sa tree na naglalarawan sa estado ng file sa oras ng commit. Ang chain ng mga commit ay bumubuo ng directed acyclic graph, kung saan ang bawat commit ay tumuturo sa isa o maraming parent.

# Pagsisimula ng repository
git init my-project
cd my-project

# Paggawa ng commit
echo "Hello, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Pagtingin ng kasaysayan
git log --oneline --graph --all

Gumagamit ang Git ng tatlong pangunahing lugar: working directory (mga file sa disk), staging area (index kung saan napupunta ang mga inihandang file) at repository (kasaysayan ng commit). Ang utos na git add ay naglilipat ng mga pagbabago mula sa working directory papunta sa staging, at git commit ay nagtatala ng nilalaman ng staging sa repository. Ang paghihiwalay na ito ay nagpapahintulot sa developer na bumuo ng makabuluhang commit mula sa isang set ng mga pagbabago, nang hindi itinatala ang bawat pag-aayos nang hiwalay.

Mga pangunahing utos ng Git

Ang mga pangunahing utos ng Git ay sumasaklaw sa 90% ng araw-araw na operasyon ng developer. Ang utos na git clone ay gumagawa ng lokal na kopya ng malayuang repository, git pull ay kumukuha ng mga pagbabago mula sa server at isinasama ang mga ito sa kasalukuyang branch, at git push ay nagpapadala ng mga lokal na commit sa server. Ang tatlong utos na ito ay bumubuo ng pangunahing cycle ng pagtatrabaho sa Git.

Para sa pagtingin ng estado ginagamit ang git status — ipinapakita nito kung aling mga file ang nabago, alin ang naidagdag sa staging, at alin ang hindi sinusubaybayan. git diff ay nagpapakita ng mga konkretong pagbabago sa file bago idagdag sa staging. Nasa ibaba ang talahanayan ng mga pinakamadalas gamitin na utos:

Para sa pag-undo ng mga pagbabago, nag-aalok ang Git ng ilang opsyon. git reset ay naglilipat ng branch pointer sa tinukoy na commit at maaaring i-reset ang staging o working directory. git revert ay gumagawa ng bagong commit na nag-uundo ng mga pagbabago ng tinukoy na commit — ito ay isang ligtas na paraan ng pag-undo para sa mga shared branch, dahil ang kasaysayan ay hindi isinusulat muli.

Pagsasanga sa Git: main, feature at release

Ang mga branch sa Git — ay magaang na nagagalaw na pointer sa isang partikular na commit. Ang paggawa ng bagong branch ay hindi kumukopya ng file, gumagawa lamang ng bagong pointer, na ginagawang halos instant ang pagsasanga. Ang branch na main (dati master) — ang pangunahing branch ng proyekto na naglalaman ng stable, handa nang i-release na code.

Ang standard practice ay ang paggamit ng Git Flow o GitHub Flow. Sa Git Flow ginagamit ang mga branch: main (release code), develop (integration branch), feature/* (bagong feature), release/* (paghahanda ng release) at hotfix/* (apurahang pag-aayos). Ang GitHub Flow ay mas simple: main at feature branch lamang, at lahat ng pagbabago ay inihatid sa pamamagitan ng Pull Request.

# Paggawa at paglipat ng branch
git branch feature-auth
git checkout feature-auth
# o gamit ang isang utos:
git checkout -b feature-auth

# Listahan ng branch
git branch --list
git branch -a  # lahat ng branch, kasama ang mga remote

# Pagbura ng branch
git branch -d feature-auth

Isang mahalagang katangian ng pagsasanga sa Git — ang kakayahang cherry-pick: paglipat ng indibidwal na commit mula sa isang branch patungo sa isa pa gamit ang utos na git cherry-pick <hash>. Ito ay kapaki-pakinabang kapag kailangan mong ilipat ang isang bugfix mula sa feature branch patungo sa release nang hindi isinasama ang buong branch. Sinusuportahan din ng Git ang rebase at interactive rebase (git rebase -i) para sa pagsasama, muling pag-aayos at pag-edit ng mga commit.

Pagsasama: Merge at Rebase

Merge (pagsasama) ay gumagawa ng espesyal na merge-commit na may dalawang parent. Ang commit na ito ay nagtatala ng katotohanan ng pagsasama ng dalawang branch at pinapanatili ang buong kasaysayan — makikita kung saan at kailan naganap ang pagsasama. Pinapanatili ng Merge ang kasaysayan sa anyo kung saan ito ginawa, na nagpapasimple ng audit, ngunit ginagawang mas kumplikado ang commit graph.

Rebase (pag-rebase) sa halip na gumawa ng merge-commit ay naglilipat ng mga commit ng kasalukuyang branch sa tuktok ng target na branch. Ang kasaysayan ay nagiging linear — lumilikha ito ng impresyon na ang development ay naganap nang sunud-sunod. Gayunpaman, isinusulat muli ng rebase ang kasaysayan, binabago ang SHA-1 hash ng mga commit, na ginagawa itong mapanganib para sa mga shared branch na may access ang ibang developer.

Rekomendasyon para sa pagpili: gamitin ang merge para sa pampublikong branch kung saan ang kasaysayan ay nakikita ng ibang developer (feature → develop), at rebase para sa lokal na trabaho kapag kailangan mong ilapat ang sariwang pagbabago mula sa main papunta sa iyong feature branch bago gumawa ng Pull Request. Ang patakaran ay simple: kung ang commit ay naipadala na sa server — huwag itong i-rebase.

Paglutas ng mga conflict

Conflict sa pagsasama ay nangyayari kapag hindi awtomatikong pagsamahin ng Git ang mga pagbabago sa isang file. Minamarkahan ng Git ang magkasalungat na bahagi sa file ng mga espesyal na marker: <<<<<<< (ating mga pagbabago), ======= (paghihiwalay), >>>>>>> (kanilang mga pagbabago). Manu-manong ina-edit ng developer ang file, pinipili ang gustong opsyon o pinagsasama ang pareho, at tinatapos ang pagsasama gamit ang commit.

Pagtatrabaho gamit ang malayuang repository

Malayuang repository (remote) — isang kopya ng Git repository na matatagpuan sa server. GitHub, GitLab at Bitbucket ay ang pinakasikat na platform para sa pag-host ng malalayong repository. Nagbibigay sila ng web interface para sa pagtingin ng code, pamamahala ng access, code review at integrasyon sa CI/CD system.

Sa Git maaaring i-configure ang maraming malalayong repository para sa isang proyekto. Bilang default, ang pangunahing remote ay tinatawag na origin. Ang utos na git remote add ay nagdaragdag ng bagong remote, git fetch ay kumukuha ng mga pagbabago nang walang pagsasama, at git pull ay pinaikling para sa git fetch + git merge. Para sa pagtatrabaho gamit ang code sa pamamagitan ng Pull Request, ang developer ay gumagawa ng fork ng repository, clino-clone ito, nagtatrabaho sa feature branch at nagpapadala ng request para sa pagsasama sa orihinal na repository.

# Pagdaragdag ng malayuang repository
git remote add origin https://github.com/user/repo.git

# Pagtingin ng malalayong repository
git remote -v

# Pagpapadala ng branch sa server
git push -u origin feature-auth

# Pagkuha ng mga pagbabago mula sa malayuang branch
git pull origin main

Sinusuportahan ng malalayong repository ang pagta-tag para sa pagmamarka ng mga release version. Ang mga tag ay maaaring light (pointer lamang sa commit) at annotated (naglalaman ng metadata: may-akda, petsa, mensahe). Ang annotated tag ay inirerekomenda para sa release version, dahil naghahatid sila ng kumpletong impormasyon tungkol sa bersyon at maaaring pirmahan ng GPG key para sa beripikasyon ng pagmamay-ari.

Git Worktree para sa parallel na trabaho

Git Worktree ay nagpapahintulot ng sabay-sabay na pagtatrabaho sa maraming branch sa iba't ibang direktoryo nang hindi lumilipat sa pagitan nila. Ang utos na git worktree add ../feature-auth feature-auth ay gumagawa ng bagong working directory na feature-auth, kung saan maaaring sumulat ng code nang hindi binabago ang branch sa pangunahing direktoryo. Ang Worktree ay kapaki-pakinabang para sa mabilisang pag-aayos sa release branch kapag ang pangunahing direktoryo ay abala sa pangmatagalang development.

Git Submodules para sa mga dependency

Git Submodules — mekanismo para sa pagsasama ng isang Git repository sa isa pa. Ang submodule ay nag-iimbak ng reference sa isang nakapirming commit ng panlabas na repository, na ginagarantiyahan ang reproducibility ng build. Ang utos na git submodule add https://github.com/example/lib.git ay nagdaragdag ng panlabas na library bilang submodule. Sa pag-clone ng proyekto na may submodule, kailangang isagawa ang git submodule update --init --recursive para mai-load ang lahat ng dependency.