git push: paano ipadala ang mga pagbabago sa remote repository

Ano ang ginagawa ng git push

Kinukuha ng git push ang mga commit mula sa lokal ninyong branch na wala pa sa server, ipinapadala ang mga ito sa remote repository (karaniwang tinatawag na origin), at inililipat doon ang pointer ng branch sa inyong pinakahuling commit. Hindi napupunta kahit saan ang mga file sa working directory o ang mga hindi pa naka-commit na pagbabago: history lang, ibig sabihin ang mga commit, ang ipinapadala.

Mahalagang maintindihan na hindi "sync" ang push. Isang direksyon lang ito: mula sa lokal na repository papunta sa remote. Para makuha ang pagbabago ng iba, kailangan ang git fetch o git pull. Kapag nalito ang dalawang direksyong ito, halos lahat ng problemang dinadala ng mga baguhan sa mentor ay lumilitaw.

Isa pang tuntunin ng Git: bilang default, ang push ay pinapayagan lang bilang fast-forward. Tatanggapin ng server ang inyong mga commit kung nagpapatuloy ang mga ito sa history na nasa server na. Kung may nauna nang nagpadala ng sarili nilang commit, tatanggihan ang push ninyo, at proteksyon ito, hindi error.

Syntax ng command

git push [<remote>] [<lokal-na-branch>[:<remote-na-branch>]]

Kapag tinawag ang git push nang walang argumento, kukunin ng Git ang kasalukuyang branch at ipapadala ito sa branch na nakatakda bilang upstream (sinusubaybayan). Kapaki-pakinabang ang tahasang anyo kapag wala pang upstream, o kapag gusto ninyong ipadala ang branch sa ibang pangalan:

git push origin main                  # ipadala ang lokal na main sa origin/main
git push origin feature/login         # ipadala ang branch na feature/login
git push origin fix:hotfix-123        # ipadala ang lokal na fix bilang hotfix-123 sa server
git push origin HEAD                  # ipadala ang kasalukuyang branch sa parehong pangalan

Paano ipadala ang mga pagbabago sa unang pagkakataon

Ganito ang karaniwang daan mula sa bagong project hanggang sa code na nasa GitHub o GitLab. Una, gumawa kayo ng walang lamang repository sa server, tapos ikakabit ninyo rito ang lokal na repository at ipapadala ang branch.

git init
git add .
git commit -m "Unang commit"
git branch -M main
git remote add origin git@github.com:user/project.git
git push -u origin main

Ikinakabit ng flag na -u (buong anyo na --set-upstream) ang lokal na branch na main sa remote na origin/main. Pagkatapos nito, puwede na lang i-type ang git push at git pull, at ipapakita na ng git status kung ilang commit ang nauuna o nahuhuli kayo sa server.

Para makita kung saan nakaturo ang remote, gamitin ang git remote -v. Kung mali ang address, itama ito gamit ang git remote set-url origin <bagong-address>, hindi sa pagbura at paggawang muli ng repository.

Paano ipadala ang bagong branch

Gumawa kayo ng branch para sa task, nag-commit, at nagta-type ng git push. Ganito ang sagot ng Git:

fatal: The current branch feature/login has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature/login

Hindi ito error kundi paalala: wala pang katapat sa server ang branch. Patakbuhin ang iminumungkahing command, o ang maikling git push -u origin feature/login. Para awtomatikong gawin ito ng Git sa lahat ng bagong branch, i-enable ang setting (available mula Git 2.37):

git config --global push.autoSetupRemote true

Bakit tinanggihan ang git push: rejected, non-fast-forward

Ito ang pinakakaraniwang sitwasyon sa team work:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:user/project.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Naunahan kayo ng katrabaho sa pagpapadala ng sariling commit. Nagkahiwalay ang history ninyo at ng server, at kung tinanggap ng Git ang push ninyo, mawawala ang mga commit ng katrabaho. Ang tamang solusyon ay kunin muna ang mga pagbabago at ilagay ang sarili ninyo sa ibabaw nito:

git pull --rebase       # kunin ang commit ng iba at ilagay ang sa inyo sa ibabaw
# kung may conflict: ayusin ang mga file, git add, git rebase --continue
git push

Puwede ring gawin ang normal na git pull sa halip na --rebase; lilitaw ang merge commit. Tama ang dalawa; sa karamihan ng team, mas gusto ang rebase para sa sariling lokal na commit, para tuwid ang history. Ang mahalaga: huwag lutasin ang pagtanggi gamit ang --force.

git push --force at --force-with-lease

Kailangan ang force push kapag sinadya ninyong isinulat ulit ang history ng sarili ninyong branch: gumawa kayo ng git commit --amend, git rebase, o pinagsama ang mga commit bago ang review. Hindi tatanggapin ng ordinaryong push ang ganitong branch, dahil ang mga lumang commit sa server ay hindi na mga ninuno ng bago.

git push --force-with-lease

Ire-rewrite ng --force-with-lease ang branch sa server, pero kung nasa parehong puwesto pa rin ito na nakita ng lokal ninyong Git (sa reference na origin/<branch>). Kung nakapagpadala na ng bagong bagay ang katrabaho, tatanggihan ng command, at hindi ninyo mabubura ang trabaho niya. Ang ordinaryong --force (-f) ay walang ganitong pagsusuri at tahimik na nag-o-overwrite ng lahat.

May isang bitag: kung nagpatakbo muna kayo ng git fetch, mag-u-update ang reference na origin/<branch>, at hihinto ang proteksyon. Iisipin ng Git na nakita ninyo ang mga commit ng iba. Kaya huwag mag-fetch nang diretso bago ang force push nang hindi muna tinitingnan kung ano ang dumating.

Sa mga shared branch (main, develop), hindi puwedeng mag-force push: mag-iiba ang history ng lahat ng nakakuha na ng lumang bersyon sa server. Kadalasan, protektado rin ang mga branch na ito sa settings ng repository, at ibabalik ng server ang protected branch hook declined.

Paano ipadala ang mga tag

Hindi ipinapadala ng karaniwang git push ang mga tag. Kailangan itong ibigay nang tahasan:

git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0          # isang tag
git push --tags                 # lahat ng lokal na tag
git push --follow-tags          # mga commit at annotated na tag na tumuturo sa mga ito

Mas maginhawa ang --follow-tags kaysa --tags: hindi nito ipapadala ang mga aksidenteng lightweight na tag sa lokal; annotated na tag lang na maaabot mula sa mga ipinapadalang commit ang kasama.

Paano burahin ang branch sa server

Ang pagbura ay ginagawa rin sa pamamagitan ng push:

git push origin --delete feature/login
# lumang syntax, pareho ang ginagawa:
git push origin :feature/login

Nananatili ang lokal na branch; puwede itong burahin gamit ang git branch -d feature/login. Sa mga katrabaho, mananatili pa ang reference na origin/feature/login hangga't hindi sila nagpapatakbo ng git fetch --prune.

Mga kapaki-pakinabang na flag ng git push

Karaniwang error sa git push at paano ayusin

Permission denied (publickey)

Hindi tinanggap ng server ang SSH key ninyo. I-check kung umiiral ang key (ls ~/.ssh), kung nasa account na ang public na bahagi, at kung gumagana ang koneksyon: ssh -T git@github.com. Kung HTTPS ang nakalagay sa remote, hihingin ng Git ang login at token, hindi ang key; tingnan ang git remote -v.

Authentication failed sa HTTPS

Matagal nang hindi tumatanggap ang GitHub at maraming ibang serbisyo ng password ng account sa HTTPS. Kailangan ng personal access token, o lumipat sa SSH. Makakatulong sa pag-iimbak ng token ang credential helper: git config --global credential.helper store (nag-iimbak sa plain text) o ang credential manager ng inyong OS.

src refspec main does not match any

Walang branch na ganoon ang pangalan. Kadalasan, walang commit pa sa bagong repository, o master ang pangalan ng branch. Tingnan ang git branch, gumawa ng commit, o palitan ang pangalan: git branch -M main.

Everything up-to-date, kahit may pagbabago

Nakalimutan ninyong mag-commit. Ipinapadala ng git push ang mga commit, hindi ang mga file. Patakbuhin ang git status, tapos git add at git commit. Ang pangalawang posibilidad: wala kayo sa branch na inaakala ninyong ipapadala.

Masyadong malaki ang file

Naglilimita ang mga serbisyo sa laki ng file (sa GitHub, 100 MB). Kapag nasa history na ang ganitong file, hindi sapat na burahin ito sa bagong commit: kailangang isulat ulit ang history, o alisin ito sa mga hindi pa naipapadalang commit (git reset --soft, tapos mag-commit ulit). Para sa malalaking binary file, ginagamit ang Git LFS.

Araw-araw na daloy ng trabaho gamit ang git push

1. git switch -c feature/x: branch para sa task.
2. Mag-commit sa maliliit at lohikal na hakbang.
3. git fetch at git rebase origin/main: kunin ang sariwang pangunahing branch.
4. git push -u origin feature/x: ilathala ang branch.
5. Magbukas ng pull request; pagkatapos ng review, mag-commit pa at ulit ng karaniwang git push.
6. Kung kinailangang isulat ulit ang history: git push --force-with-lease.

Bago magpadala, makabubuting tingnan kung ano ang aalis papunta sa server: ipapakita ng git log origin/main..HEAD --oneline ang mga commit na wala pa sa server.

Ano ang i-configure nang isang beses

Ilang global na setting ang makakaiwas sa karamihan ng sorpresa sa pagpapadala. Tinutukoy ng push.default kung ano ang ipapadala ng git push nang walang argumento. Ang default sa modernong bersyon ay simple: kasalukuyang branch lang ang ipinapadala, at sa upstream na may parehong pangalan lang. Bihirang kailangang palitan ito, pero makabubuting tingnan kung wala nang natitirang matching sa lumang config, dahil ipinapadala nito nang sabay-sabay ang lahat ng branch na may magkatugmang pangalan.

git config --global push.default simple
git config --global push.autoSetupRemote true
git config --global push.followTags true
git config --global pull.rebase true

Ginagawang default na asal ng push.followTags ang --follow-tags, at inaalis ng pull.rebase ang hindi kailangang merge commit kapag tinanggihan ang push at kailangan munang kunin ang pagbabago ng iba.

Ang pre-push hook

Tumatakbo ang file na .git/hooks/pre-push bago ang pagpapadala. Kapag nagtapos ito na may non-zero code, hindi matutuloy ang push. Madalas na nagpapatakbo rito ang mga team ng test o linter, para hindi makarating sa server ang sirang code. Iwasang laktawan ang hook gamit ang --no-verify maliban kung malinaw sa inyo kung bakit ito pumapalya.

Buod

Inilalathala ng git push ang inyong mga commit sa remote repository, at isang direksyon lang ito. Gawin ang unang pag-push ng branch gamit ang -u; kapag tinanggihan, kunin muna ang pagbabago ng iba gamit ang pull; at ang muling isinulat na history ng sarili ninyong branch ay ipadala lang gamit ang --force-with-lease. Ang pakikitungo sa remote repository, push, pull, at SSH key ay itinuturo nang praktikal sa kursong Git namin.