Mag-push — ano ito, paano gumagana ang git push at kailan kailangan

Ano ang push sa Git

Ang Git push ay isang command na naglilipat ng mga commit mula sa lokal na repository patungo sa malayuang repository. Hindi tulad ng commit na nagse-save ng mga pagbabago lamang sa lokal na makina ng developer, ang push ay nag-publish ng mga pagbabagong ito para sa buong team. Push ay isang mandatoryong hakbang bago gumawa ng Pull Request at mag-deploy.

Ang arkitektura ng Git ay nag-aakala na ang bawat developer ay nagtatrabaho sa kanilang sariling lokal na repository. Ang mga commit ay ginagawa nang lokal at nag-iipon hanggang sa magpasya ang developer na i-push ang mga ito. Ito ay nagbibigay ng kalayaan: maaaring gumawa ng maraming lokal na commit, mag-eksperimento, at muling isulat ang kasaysayan nang hindi naaapektuhan ang mga kasamahan.

# Push sa origin remote, main branch
git push origin main

# I-push ang kasalukuyang branch sa remote na may upstream
git push -u origin feature/new-dashboard

# I-push ang lahat ng branch na may katugmang pangalan
git push --all origin

# Force push na may lease (ligtas na force push)
git push --force-with-lease

Pagkatapos ng push, ina-update ng malayuang repository ang mga refs (mga reference sa mga branch) upang tumuro sa mga bagong commit. Ang ibang mga developer ay maaaring makuha ang mga pagbabagong ito sa pamamagitan ng git pull o git fetch. Ito ang palitan ng mga commit na bumubuo sa batayan ng collaborative development.

Paano gumagana ang git push

Ang command na git push ay nagkukumpara ng lokal at malayuang mga branch at naglilipat lamang ng mga nawawalang commit. Hindi muling ipinapadala ng Git ang lahat ng file — nagpapadala lamang ito ng delta, na ginagawang mabilis ang push kahit sa malalaking repository. Git Protocol ay gumagamit ng smart transfer na nagpapaliit sa dami ng ipinadalang data.

Kung ang malayuang branch ay naglalaman ng mga commit na wala sa lokal, ang push ay tatanggihan. Ito ay isang mekanismo ng proteksyon na pumipigil sa pagkawala ng mga pagbabago. Sa sitwasyong ito, dapat munang mag-execute ng git pull ang developer, pagsamahin ang mga pagbabago, at pagkatapos ay mag-push muli. Ang alternatibo ay force push, na nire-overwrite ang malayuang branch, ngunit dapat itong gamitin nang may pag-iingat.

Ang pag-unawa sa malalayuang repository ay susi sa tamang push. Karaniwang ginagamit ang origin — ang default na pangalan ng malayuang repository. Ang command na git remote -v ay nagpapakita ng listahan ng malalayuang repository at kanilang mga URL. Maaaring magdagdag ng maraming remote (halimbawa, origin para sa pangunahing repository at upstream para sa fork).

Kailan dapat mag-push ng mga pagbabago

Ang pangunahing panuntunan: dapat mag-push pagkatapos ng bawat lohikal na natapos na yugto ng trabaho. Kung natapos ng developer ang isang gawain o bahagi nito — oras na para mag-push. Gayunpaman, ang pag-push ng hindi tapos na trabaho na sumisira sa build ay hindi inirerekomenda. Hindi sirang build ay ang minimum na kinakailangan para sa push sa anumang branch.

Sa pag-develop ng team, ang sumusunod na ritmo ay tinatanggap: sa umaga — git pull upang makuha ang mga pagbabago ng mga kasamahan, sa maghapon — ilang commit at isa o dalawang push, sa gabi — huling push ng lahat ng natapos na gawain. Kung mas madalas mag-push ang developer, mas maliit ang panganib ng mga conflict sa pagsasama ng mga branch at mas transparent ang progreso ng trabaho.

• Pagkatapos matapos ang gawain — mag-commit at i-push ang huling solusyon sa feature branch
• Bago umuwi — i-push ang hindi tapos na trabaho sa feature branch (hindi sa main!)
• Bago gumawa ng PR — tiyakin na lahat ng commit ay nai-push at available para sa review
• Pagkatapos ng rebase — mag-push gamit ang --force-with-lease sa sariling feature branch

Mga panuntunan ng ligtas na push

Ang ligtas na push ay isang set ng mga panuntunan na pumipigil sa pagkawala ng data at mga conflict sa team. Ang una at pinakamahalagang panuntunan: huwag kailanman mag-push nang direkta sa main o master branch, kung hindi naka-configure ang direktang deploy sa proyekto. Sa modernong mga team, ang proteksyon ng main branch ay naka-configure sa antas ng GitHub branch protection.

Ikalawang panuntunan: bago mag-push, mag-sync sa malayuang branch. I-execute ang git pull --rebase upang maiwasan ang merge commit sa pagsasama. Pinapasimple nito ang kasaysayan at ginagawa itong linear. Kung ang push ay tinanggihan — huwag gumamit ng bare force push, kundi suriin muna kung anong mga commit ang lumitaw sa malayuang branch.

Ikatlong panuntunan: i-configure ang mga pre-push hook na awtomatikong nagpapatakbo ng mga test at linter bago ipadala. Kung ang mga test ay bumagsak — ang push ay haharangin. Ang mga ganitong hook ay naka-configure sa pamamagitan ng Husky o Git hooks (pre-push file sa .git/hooks).

Ikaapat na panuntunan: huwag mag-push ng malalaking binary file. Ang Git ay hindi dinisenyo para sa pag-iimbak ng binary artifacts — pinapalaki nila ang repository at pinapabagal ang mga operasyon. Para sa malalaking file, gamitin ang Git LFS (Large File Storage). Kung ang binary file ay nai-push na at pumasok sa kasaysayan, kailangan itong alisin sa pamamagitan ng git filter-branch.

Ano ang gagawin kung hindi nag-push

Ang pinakakaraniwang dahilan ng hindi matagumpay na push — ang malayuang branch ay naglalaman ng mga commit na wala sa lokal. Ito ay nangyayari kapag ang ibang developer ay nag-push ng kanilang mga pagbabago sa parehong branch. Solusyon: mag-execute ng git pull, lutasin ang mga posibleng conflict, at ulitin ang push.

# Push tinanggihan — mag-fetch at mag-rebase muna
git fetch origin
git rebase origin/main
# Lutasin ang mga conflict, pagkatapos:
git push --force-with-lease

# O simpleng pagsamahin ang malalayuang pagbabago
git pull origin main
git push

Ikalawang dahilan — kawalan ng pahintulot na magsulat sa branch. Kung ang main branch ay protektado ng branch protection rule, ang direktang push ay ipinagbabawal. Solusyon: mag-push sa feature branch at gumawa ng Pull Request. Ang mga setting ng proteksyon ay karaniwang ina-administer sa pamamagitan ng GitHub settings o GitLab protected branches.

Ikatlong dahilan — mga problema sa pag-authenticate. Lumang credentials, paglipat sa SSH, o pagbabago ng personal access token. Solusyon: suriin ang remote URL (git remote -v) at i-update ang credentials. Mula noong 2021, tinanggal ng GitHub ang pag-authenticate ng password para sa HTTPS — gumagamit ng personal na token o SSH key.